Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.143.17.128] |
|
Данный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Сообщ.
#1
,
|
|
|
Добрый день! У меня в базе есть 3 таблицы:
1-я таблица - users (таблица пользователей, предоставляющих определенные услуги); 2-я таблица - categories (список категорий, каждый пользователь может выбрать категорию, под которую подходит его услуга); 3-я таблица - prices (для каждой категории есть свой прайс-лист, по задумке каждый пункт прайс-листа будет выполнен в виде отдельного поля таблицы, т.к. каждый пользователь будет выставлять свою цену на услугу); Я пришел к выводу, что необходимо будет создать общую таблицу users_categories_prices, которая будет содержать следующие поля: - user_id; - category_id; - price_id; - cost (Стоимость услуги конкретного пользователя). Есть ли какой-нибудь более гибкий вариант решения задачи? Возможно ли связать 3 таблицы со связью "многие ко многим"? |
Сообщ.
#2
,
|
|
|
Выполните анализ предметной области. И сразу определится, что является сущностями, а что - их атрибутами, что с чем и как связано, какие бизнес-процессы происходят и т.п.
|
Сообщ.
#3
,
|
|
|
Akina ПОзволю добавить:
И составьте модель Сущности-Связи... |
Сообщ.
#4
,
|
|
|
Цитата Лев @ Есть ли какой-нибудь более гибкий вариант решения задачи? Чем характеризуем "гибкость"? И нужна ли "гибкость", или можно без нее? (см. Бритва Оккама) Цитата Лев @ Возможно ли связать 3 таблицы со связью "многие ко многим"? Конечно возможно. Но вопрос - а надо ли? Скрытый текст (см. ответы Akina и Павла Калугина) |
Сообщ.
#5
,
|
|
|
Цитата Лев @ Есть ли какой-нибудь более гибкий вариант решения задачи? Возможно ли связать 3 таблицы со связью "многие ко многим"? Если пользователь будет выставлять цену на каждую категорию отдельно, то по другому никак не обойтись. |
Сообщ.
#6
,
|
|
|
Отсутствует четвертая таблица для хранения услуг.
price_id вещь сомнительная, и вообще смысл таблицы prices близок к нулю. |
Сообщ.
#7
,
|
|
|
Цитата p1qb0d @ price_id вещь сомнительная, и вообще смысл таблицы prices близок к нулю. Цитата Лев @ т.к. каждый пользователь будет выставлять свою цену на услугу Далеко не сомнительна. |
Сообщ.
#8
,
|
|
|
Цитата Bas @ Цитата p1qb0d @ price_id вещь сомнительная, и вообще смысл таблицы prices близок к нулю. Цитата Лев @ т.к. каждый пользователь будет выставлять свою цену на услугу Далеко не сомнительна. Чрезвычайно сомнительна, так как в таблице prices нет никаких самостоятельных параметров, требующих собственной идентификации. Вот указанная агрегирующая таблица - да, полезна, но в ней поле price_id является лишним полем. Если планируется прикрутить какую-то мултивалюту, тогда да, самостоятельная таблица prices получит смысл, а price_id будет указывать на тип валюты - тогда это будет иметь смысл. Но в постановке задачи это не озвучено. Так что пока price_id излишен. |
Сообщ.
#9
,
|
|
|
Цитата p1qb0d @ Вот указанная агрегирующая таблица - да, полезна, но в ней поле price_id является лишним полем. Ой ли лишним.... Цитата Лев @ 1-я таблица - users (таблица пользователей, предоставляющих определенные услуги);2-я таблица - categories (список категорий, каждый пользователь может выбрать категорию, под которую подходит его услуга);3-я таблица - prices (для каждой категории есть свой прайс-лист, по задумке каждый пункт прайс-листа будет выполнен в виде отдельного поля таблицы, т.к. каждый пользователь будет выставлять свою цену на услугу); ТО есть Исполнитель, услуга и прайс по услуге остается их связать и получить прайс по пользователю по всем услугам, что и делает автор Вот зачем он добавляет cost не понятно. Хотя в случае "спец предложений" это может пригодится. Но тогда разумнее вести в связи период актуальности (связь актуальна с .. .по ...) А вообще описание предметной области и ER модель крайне упростили бы ответ на вопрос автора |