форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[ Отслеживать ]

"Организация составных заказов.Вопрос по схеме данных"

Сообщение от Eye on 24-Июл-08, 17:21

Допустим имеем составной заказ, который состоит из подзаказов. Например, заказываем стол, а это влечет за собой заказ дерева в цех, заказ дизайнерского решения.(пример налету придумал) Каждый из подзаказов имеет свои параметры. Вариант реализации:   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 ------------------------ Придется эту логику выносить в код. Может в действительность все делается иначе? Не хочу изобретать велосипед...

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Организация составных заказов.Вопрос по схеме данных"

Сообщение от angra (ok) on 25-Июл-08, 01:12

Нельзя говорить о производительности на абстрактных примерах, так что этот момент можем сразу опустить. Возьмем за основу второй вариант и добавим ему универсальности. Создадим таблицу Component_fields ------------------- id_order_component field_name field_value ------------------- field_value скорее всего varchar достаточный для всех возможных значений. Итого по заказу мы выбираем из Order_components нужные id_order_component и для каждого из них набор полей и значений. Также можно добавить таблицу Component_fields_desc, в которой хранить список имен полей для каждого типа компонента, это избавит нас от необходимости харкодинга и позволит добавлять новые типы компонентов редактированием базы, а не модификацией кода. Слишком много джойнов чаще всего плохо сказываются на производительности, однако есть различные методы борьбы с этим, например кешированием во временных таблицах.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Организация составных заказов.Вопрос по схеме данных"
	Сообщение от Eye on 25-Июл-08, 09:42
	>[оверквотинг удален] >id_order_component >field_name >field_value >------------------- >field_value скорее всего varchar достаточный для всех возможных значений. Итого по заказу >мы выбираем из Order_components нужные id_order_component и для каждого из них >набор полей и значений. Также можно добавить таблицу Component_fields_desc, в которой >хранить список имен полей для каждого типа компонента, это избавит нас >от необходимости харкодинга и позволит добавлять новые типы компонентов редактированием базы, >а не модификацией кода. Спасибо большой, это новый вариант для меня :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]