Архитектура базы данных, прошу помощи))

Добрый день! У меня в базе есть 3 таблицы:
1-я таблица - users (таблица пользователей, предоставляющих определенные услуги);
2-я таблица - categories (список категорий, каждый пользователь может выбрать категорию, под которую подходит его услуга);
3-я таблица - prices (для каждой категории есть свой прайс-лист, по задумке каждый пункт прайс-листа будет выполнен в виде отдельного поля таблицы, т.к. каждый пользователь будет выставлять свою цену на услугу);

Я пришел к выводу, что необходимо будет создать общую таблицу users_categories_prices, которая будет содержать следующие поля:
- user_id;
- category_id;
- price_id;
- cost (Стоимость услуги конкретного пользователя).

Есть ли какой-нибудь более гибкий вариант решения задачи? Возможно ли связать 3 таблицы со связью "многие ко многим"?

Выполните анализ предметной области. И сразу определится, что является сущностями, а что - их атрибутами, что с чем и как связано, какие бизнес-процессы происходят и т.п.

Akina ПОзволю добавить:
И составьте модель Сущности-Связи...

Цитата Лев @ 10.12.14, 14:09

Есть ли какой-нибудь более гибкий вариант решения задачи?

Чем характеризуем "гибкость"? И нужна ли "гибкость", или можно без нее? (см. Бритва Оккама)

Цитата Лев @ 10.12.14, 14:09

Возможно ли связать 3 таблицы со связью "многие ко многим"?

Конечно возможно. Но вопрос - а надо ли?

Скрытый текст

(см. ответы Akina и Павла Калугина)

Сообщение отредактировано: JoeUser - 10.12.14, 22:32

Цитата Лев @ 10.12.14, 14:09

Есть ли какой-нибудь более гибкий вариант решения задачи? Возможно ли связать 3 таблицы со связью "многие ко многим"?

Если пользователь будет выставлять цену на каждую категорию отдельно, то по другому никак не обойтись.

Отсутствует четвертая таблица для хранения услуг.

price_id вещь сомнительная, и вообще смысл таблицы prices близок к нулю.

Цитата p1qb0d @ 10.12.15, 06:09

price_id вещь сомнительная, и вообще смысл таблицы prices близок к нулю.

Цитата Лев @ 10.12.14, 14:09

т.к. каждый пользователь будет выставлять свою цену на услугу

Далеко не сомнительна.

Цитата Bas @ 10.12.15, 07:34

Цитата p1qb0d @ 10.12.15, 06:09

price_id вещь сомнительная, и вообще смысл таблицы prices близок к нулю.

Цитата Лев @ 10.12.14, 14:09

т.к. каждый пользователь будет выставлять свою цену на услугу

Далеко не сомнительна.

Чрезвычайно сомнительна, так как в таблице prices нет никаких самостоятельных параметров, требующих собственной идентификации.

Вот указанная агрегирующая таблица - да, полезна, но в ней поле price_id является лишним полем.

Если планируется прикрутить какую-то мултивалюту, тогда да, самостоятельная таблица prices получит смысл, а price_id будет указывать на тип валюты - тогда это будет иметь смысл.

Но в постановке задачи это не озвучено. Так что пока price_id излишен.

Цитата p1qb0d @ 10.12.15, 10:01

Вот указанная агрегирующая таблица - да, полезна, но в ней поле price_id является лишним полем.

Ой ли лишним....

Цитата Лев @ 10.12.14, 14:09

1-я таблица - users (таблица пользователей, предоставляющих определенные услуги);2-я таблица - categories (список категорий, каждый пользователь может выбрать категорию, под которую подходит его услуга);3-я таблица - prices (для каждой категории есть свой прайс-лист, по задумке каждый пункт прайс-листа будет выполнен в виде отдельного поля таблицы, т.к. каждый пользователь будет выставлять свою цену на услугу);

ТО есть Исполнитель, услуга и прайс по услуге
остается их связать и получить прайс по пользователю по всем услугам, что и делает автор
Вот зачем он добавляет cost не понятно. Хотя в случае "спец предложений" это может пригодится. Но тогда разумнее вести в связи период актуальности (связь актуальна с .. .по ...)
А вообще описание предметной области и ER модель крайне упростили бы ответ на вопрос автора