Привет всем.

Разрабатываю программу для мебельной фабрики. Фабрика занимается как производством стандартной мебели (готовые чертежи, отлаженое производство) так и производством мебели под заказ.

Упрощенная схема:
- справочник стандартной мебели:
Заголовок (название, габаритные размеры..)
Спецификация (длина, ширина, признак криволинейности, код программы станка), т.е. детали относящиеся к конкретному изделию... Есть еще набор парамметров, но это не суть важно, просто хочу подчеркнуть, что их достаточно много.

- заказ
Заголовок (дата, номер, клиент...)
Спецификация ???
Вот тут не знаю как лучше поступить.. в первой версии программы я сделал две спецификации: 1-для стандартной мебели, 2-для не стандартной. В первом случае, я только хранил ссылку на справочник стандартных изделий и все детали вытаскивал из него. Во-втором случае дублировались все поля справочника станд.мебели поскольку данных по не стандартной мебели в системе нет.
Такой вариант мне показался не очень удобным в силу не однородности обработки. Сейчас потребовалась новая версия программы и появилась мысль избавиться от спецификации для стандартной мебели в заказе, а оставить только для не стандартной (+ ид станд.мебели - позволит различать стандарт/не стандарт). При оформлении заказа оператор выбирает стандартное изделие и все его данные копируются в заказ. Т.о. я добиваюсь однородности обработки заказа, но теряю возможность отображать исправления в справочнике стандартной мебели на заказы...
Фактически при такой схеме справочник стандартной мебели превращается в набор шаблонов.

Посоветуйте как поступить.

Сахават
СЮ> Сначала создайте спецификацию для заказа, запихните ее в
СЮ> стандартные(шаблоны), а потом выбирайте из стандартных стандартно.
Не очень понял, поясните пожалуйста.

Сахават
СЮ> (Как вы узнаете, что стандартно, а что нет? Кто Вам поставляет эту
СЮ> информацию?)
Если речь об операторе, то он работает с клиентом и четко знает какие изделия стандартные, а какие нет.
Если речь о том как я буду в данных различать, то наличие null в FK означает не стандартное изделие.


--
Dik76

Posted via ActualForum NNTP Server 1.3

Programmer_Ortodox
PO> В подобных случаев нужно задаваться неким полем(свойством) и
PO> устанавливать ему конкретное значение, для предупреждения "кривотолков"
Да меня смущает не то как различить стандартное изделие от не стандартного (доп. поле или FK к справ.станд. мебели с возм.
установки null), а сам подход. Стоит ли держать копию данных станд. изделия в заказе или все же лучше тянуть данные из справочника,
а следовательно в отдельной сущности?
Сам склоняюсь к тому чтоб объеденить в заказе стандарт и не стандарт.

--
Dik76

Posted via ActualForum NNTP Server 1.3

ModelR

M> Как правило, это приводит к вопросу об истории.
M> Пока производство делает, в стандарте что-нибудь поменяется.
M> От этой проблемы избавляет либо копирование стандарта в заказ полностью,
M> либо история данных стандарта.

Спасибо всем откликнувшимся. Буду копировать стандарт в заказ. Тем более блобов у меня там нет..

--
Dik76

Posted via ActualForum NNTP Server 1.3