таблицы order и order_lines - дублировать данные или использовать управление версиями?

Question

Разве плохо дублировать названия и цены в таблицы order_lines (ссылки из таблиц продуктов и опций)?

Я проверил несколько популярных PHP-скриптов с открытым исходным кодом для электронной коммерции, и он это делает.

Предположим, что следующие таблицы (быстрый пример):

product таблица:

+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| product_id | int(11)      | NO   | PRI | NULL    | auto_increment |
| name       | varchar(150) | NO   |     | NULL    |                |
+------------+--------------+------+-----+---------+----------------+

options таблица: (продукт может иметь 1 или более вариантов, например: маленький, большой, х-большой и т. Д.)

+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| option_id  | int(11)      | NO   | PRI | NULL    | auto_increment |
| product_id | int(11)      | NO   |     | NULL    |                |
| name       | varchar(150) | NO   |     | NULL    |                |
| price      | decimal(6,2) | NO   |     | NULL    |                |
+------------+--------------+------+-----+---------+----------------+

Компания будет получать около 5000 новых заказов в день, я ищу разумный способ, как оформить заказ, таблицы order_line? Вы дублируете имена и цены в таблицу order_lines? Сотни цен будут меняться каждые несколько месяцев из таблицы options.

Я читал о версии (Тип 2), я не уверен, как она на самом деле работает, насколько я понимаю, я могу добавить поле version_id в таблицы product, options и order_line. Каким бы ни был MAX version_id, это означает последнюю версию. Это кажется намного проще, чем при использовании дизайна StartDate и EndDate.

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

Answer 1

Ваша таблица options невелика (по размеру строки, а не по количеству строк), поэтому сохранение имени несколько раз не должно быть проблемой. Однако если вы хотите убедиться, что одна и та же строка используется для всех опций «Large», то извлечение строк в справочную таблицу поможет.

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

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

Даты могут быть немного проще в использовании, так как вы можете использовать триггеры для обновления таблицы, записывая CURRENT_TIMESTAMP в таблицу без необходимости знать предыдущий номер версии. Использование номера версии требует обновления до обновления.

Возможно, вам будет полезно взглянуть на «Разработка баз данных, ориентированных на время» Ричарда Снодграсса, доступно бесплатно h = здесь: http://www.cs.arizona.edu/~rts/publications.html

РЕДАКТИРОВАТЬ: Таблица с информацией о версии обычно имеет поле даты / времени, содержащее дату «valid_from» для этой строки. Новые строки будут автоматически заполнены CURRENT_TIMESTAMP, чтобы вы знали, какая строка самая последняя. Другие методы используют два поля для записи времени начала и окончания, когда строка была действительной. Использование двух полей упрощает запросы, так как вы можете выполнить команду «SELECT ... WHERE point_in_time BETWEEN start_date AND end_date»