Проблема дизайна базы данных

Question

У меня есть таблица заказов.Каждый заказ может иметь один и тот же продукт несколько раз. Количество недостаточно , поскольку у каждого продукта могут быть свои предпочтения!Так что мне интересно, что лучше сделать ...

Идентификатор заказа PK-id идентификатор продукта?Первичный ключ - PK-id

или
Таблица заказов
(идентификатор заказа, строка заказа) в виде PK ..

Затем другая таблица
Строки заказа
(идентификатор заказа, строка заказа, продукция) как PK

А затем
OrderLinesPreferences
(идентификатор заказа, строка заказа, продукция, предпочтительно) как PK?

Интересно, подходит ли этот подход. Также я не знаю, что мне следует делать с индексированием, чтобы не замедляться при большом количестве записей.Я использую postgresql ..
Например, в таблице OrderLinesPreferences a, где order-id = 1 и productid = 10;будет быстрым или сделает полный поиск таблицы?

Answer 1

Исходя из комментария, сделанного @OP к ответу dnuttle, я бы сказал, что ситуация требует элементов и подпунктов, все из списка базовых элементов.

Итак:

PRODUCT
  product_id PK
, description
, ...

OPTIONAL_ITEM
  option_id PK
, description
, ...

ORDER
  order_id PK
, date_taken...

ORDER_ITEM
  order_id PK, FK
, item_number PK     // Or use a surrogate as PK, if you like
, product_id FK
, quantity

ORDER_ITEM_OPTION
  order_id PK, FK
, item_number, PK, FK  // Order and item FK to ORDER_ITEM
, option_id, PK, FK    // FK to OPTIONAL_ITEM
, quantity

Это дает вам то, что вам нужно, чтобы иметь заказ на один и тот же товар несколько раз и 0 или более вариантов, примененных к каждому предмету, как в кофе с различным количеством сливок, сахара и т. Д. В соответствии с требованием ОП.

Answer 2

Ни один из дизайнов, которые вы показали (как я их читал; ваши обозначения немного сбивают с толку), - это то, что я бы предложил. В ситуациях, когда OrderID, ProductID не однозначно идентифицирует позицию заказа (как в случае, когда один и тот же продукт может быть заказан несколько раз по заданному заказу), обычной практикой является использование суррогатного ключа в таблице подробностей. Например, схема будет выглядеть так:

Order (note here that table names, by convention, are in singular form)
----------
OrderID
CustomerID
...
etc.
PK is OrderID

OrderItem
-----------
OrderID
ItemNumber
ProductID
Quantity
...
etc.
PK is OrderID, ItemNumber

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

Что касается того, как хранить ваши предпочтения, вы не даете достаточно информации, чтобы ответить на него адекватно. Если у каждого отдельного элемента заказа будет ровно одно «предпочтение», то вы можете просто включить его в таблицу OrderItem. Если бы каждый элемент заказа мог иметь переменное число предпочтений, то вам нужно что-то вроде:

OrderItemPreference
------------
OrderID
ItemNumber
... preference information
PK is OrderID, ItemNumber, and something to uniquely identify the preference

Answer 3

Вот что у меня в голове:

| OrderId | ProductKey | ProductPrefKey | Qty |

Если вам нужно представить счет в определенном порядке, вам нужно будет добавить идентификатор строки, но в противном случае вы можете проигнорировать его,Вы можете сделать первичный ключ OrderId, ProductKey, ProductPrefKey, и это обеспечит вам быстрый доступ по заказам.

Поскольку это, похоже, новая реализация, имейте в виду следующее: цены на продукты часто меняютсявремя (как и адреса клиентов, купоны и т. д.), и как только вы заполните счет, вы захотите сохранить исторический учет этого.Это можно сделать, меняя ProductKey каждый раз, когда вы меняете какие-либо сведения об элементе, или вам понадобится какая-то архивная система, включающая в себя все исторические сведения, относящиеся к счету.

Answer 4

Непонятно, что вы подразумеваете под «у каждого продукта могут быть свои предпочтения». Означает ли это, что каждая строка в заказе может иметь разные вариации для одного и того же продукта? Таким образом, вы могли бы купить товар один раз, скажем, рубашку большого размера, а другой раз - среднего размера? В этом случае это звучит как продукты против SKU для меня. Вам понадобится таблица «sub-product» или «SKU», которая будет связана с таблицей продуктов, если это так. Тогда строки в вашем заказе будут связаны с SKU, а не с продуктами. Можно связать обе строки заказа, но не обязательно.