Альтернативы соединительной таблице?

Question

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

• Списка продуктов, приобретенного пользователем
• Список пользователей, которые приобрели тот или иной продукт.

Его много-много отношений.

До сих пор я мог думать только об этом.
создать таблицу для хранения заказов

table recordorders(
     userID // foreign key from users table 
     productID, // foreign key from products table 
     dateofpurchase, 
     quantity, 
     price_per_unit, 
     total_amount 
    ) 

Он будет действовать как таблица перехода.

Является ли это хорошим подходом и есть ли другие методы, чем таблица соединений, которые более эффективны и эффективны для запросов?

Answer 1

Ваши пули описывают две таблицы, а не одну. Ваша таблица соединений неправильно описана как два списка. Это набор строк информации о заказе. Таблица соединений, которую вы дали, содержит строки, где «пользователь [userID] приобрел продукт [productID] on ...». Т.е. он записывает информацию о заказе. (Комбинации пользователя, продукта, даты и т. Д. Заказов). С учетом пользователя или продукта вы можете получить соответствующую таблицу маркеров, запросив таблицу сведений о заказе.

Однако вашей таблице, вероятно, нужен другой столбец, который является уникальным идентификатором заказа. В противном случае он не может записать, что есть два порядка, одинаковые во всех этих столбцах. (Например, если один и тот же человек покупает один и тот же продукт в тот же день в том же количестве, цене и сумме.) Т.е. его строки, вероятно, не равны 1: 1 с заказами. Именно поэтому выше я назвал его таблицей информации о заказе, а не таблицей заказов. Он фиксирует, что в каком-то порядке были эти свойства; но он не записывает отдельные заказы, если могут быть заказы с одинаковой информацией. Это действительно ассоциация «много-ко-многим» и т. Д. (Для каждого столбца). Вот почему идентификатор заказа выбирается как уникальное имя для заказа в качестве дополнительной информации. Эта новая таблица будет называться таблицей сущностей, а не таблицей соединений или ассоциаций. Он содержит строки, где «пользователь [пользователь] [пользователь] приобрел ...».

PS заказ, как правило, то, что можно охарактеризовать как объединение на/из/между идентификатор заказа, пользователь, установить из порядка линий (продукт, количество, цена & всего), и другие вещи (дата, общая сумма и т. д.). Заказы обычно реляционно характеризуются таблицей сущности заказа на идентификаторе заказа с ее именем пользователя, датой и т. Д., А также таблицей связей строки заказа на идентификаторах заказа и их информацией о строке заказа.

PPS Настало время ознакомиться с книгой по информационному моделированию и дизайну базы данных.

Answer 2

Вы не «магазин», эти две вещи в таблице (Junction, или в противном случае), вы обнаружите их из сырья («Факт») данных:

Используя предложенную таблицу:

Список продуктов, приобретенных пользователем:

SELECT productID 
    FROM recordorders 
    WHERE userID = 123; 

Список пользователей, которые приобрели конкретный продукт:

SELECT userID 
    FROM recordorders 
    WHERE productID = 987;