Отношения MySQL: ставки с продуктами и пользователями

Question

У меня есть простой сайт, где пользователи могут делать ставки на товар.Модель выглядит следующим образом: Очевидно, что разные пользователи могут делать ставки, так как мне нарисовать отсутствующую ссылку на таблицу 'users'?

Я немного запутался, использовать ли идентификацию или неидентификациюотношения.Обновлено:

Answer 1

Вы говорите: "... пользователи могут делать ставки на продукт. "

Это говорит о том, что между пользователями и продуктами существует связь (ставки),Вы можете назвать это user_bids_on_product или просто bid.

Я бы удалил отношения между user и product (если это не означает что-то еще, например, владелец продукта) и объединил бы ваш bids и bids_has_product в одну таблицу:

user_bids_on_product
--------------------
product_id  FK to product
user_id     FK to user
price

(product_id, user_id) должен , а не быть первичным ключом для этой таблицы, так как мы предполагаем, что пользователь может делать несколько ставок на продукт.

Вы можете добавить суррогат id и сделать это PK или добавить столбец bid_number и сделать соединение (product_id, user_id, bid_number) PK.В качестве альтернативы вы можете сделать (product_id, bid_number) PK (bid_number может пометить порядок ставок для каждого продукта, как в данном случае аукцион).Я думаю, что решать вам.

Идентифицирующие отношения:

---

Неидентифицирующие отношения:

Answer 2

Пользователь может сделать одну Заявку на Продукт;Пользователь может делать ставки более чем на один Продукт;Продукт может иметь более одной заявки;Ставка связана только с одним продуктом.

Я думаю, что вам необходимо установить связь между пользователем и ставками, которые он делает.Это один ко многим.

Еще один вопрос, касающийся вашей обновленной диаграммы: назначит ли Пользователь оценку Продукту во многом так же, как он делает ставку?Это стоит отслеживать?Если да, я бы имел отношения между Пользователем и Рейтингом.

Answer 3

Имеет смысл простая идентификация ч / б пользователей и ставок, ставки не могут существовать без пользователя.

Это простые отношения ко многим, поскольку пользователи "has_many" делают ставки.