Допустим имеем составной заказ, который состоит из подзаказов. Например, заказываем стол, а это влечет за собой заказ дерева в цех, заказ дизайнерского решения.(пример налету придумал) Каждый из подзаказов имеет свои параметры. Вариант реализации:
Orders
----------
id
date
id_client
...
-----------Order_components
-------------------
id_order
id_materials_order
id_design_order
-------------------Materials
---------
id
material
id_color
----------Designs
----------
id
....
----------
Насколько правильная данная схема данных? У меня нет опыта работы с большими нагрузками. Единственное, что меня тут смущает, это то, что если на один заказ приходится два подзаказа на материалы, то в таблице Order_components будет две записи и будут пустые поля.
Другой вариант, это в таблице Order_components хранить только id заказа и ввести поле - идентификатор типа подзаказа, но тогда как поддерживать целостность данных на урове БД.
Order_components
-------------------
id_order
id_order_component
id_type_order_component
------------------------
Придется эту логику выносить в код.
Может в действительность все делается иначе? Не хочу изобретать велосипед...
Нельзя говорить о производительности на абстрактных примерах, так что этот момент можем сразу опустить.
Возьмем за основу второй вариант и добавим ему универсальности. Создадим таблицу
Component_fields
-------------------
id_order_component
field_name
field_value
-------------------
field_value скорее всего varchar достаточный для всех возможных значений. Итого по заказу мы выбираем из Order_components нужные id_order_component и для каждого из них набор полей и значений. Также можно добавить таблицу Component_fields_desc, в которой хранить список имен полей для каждого типа компонента, это избавит нас от необходимости харкодинга и позволит добавлять новые типы компонентов редактированием базы, а не модификацией кода.Слишком много джойнов чаще всего плохо сказываются на производительности, однако есть различные методы борьбы с этим, например кешированием во временных таблицах.
>[оверквотинг удален]
>id_order_component
>field_name
>field_value
>-------------------
>field_value скорее всего varchar достаточный для всех возможных значений. Итого по заказу
>мы выбираем из Order_components нужные id_order_component и для каждого из них
>набор полей и значений. Также можно добавить таблицу Component_fields_desc, в которой
>хранить список имен полей для каждого типа компонента, это избавит нас
>от необходимости харкодинга и позволит добавлять новые типы компонентов редактированием базы,
>а не модификацией кода.Спасибо большой, это новый вариант для меня :)