powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Хранение в базе шаблонов, а обработка - приложением(+)
11 сообщений из 11, страница 1 из 1
Хранение в базе шаблонов, а обработка - приложением(+)
    #33164675
Kezya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем здравствуйте.
Есть вот такая схема таблиц (см. рис.) Имеется: группа продуктов, подгруппа продуктов. В подгруппу могут входить как простые продукты, так и составные (ComplexProd). Составных продуктов будет очень мало - не более 5. Но дело в том, что это не составные продукты как таковые - а шаблон составных продуктов. Например, есть какой-то составной продукт, который состоит из продукта1 и продукта2. В базе данных будет описан лишь состав - продукт 1 и 2. Когда дойдет дело до использования сложного продукта, то реально надо знать соотношение продукта1 и продукта2 в составном продукте. Например, П1 может быть в 10 раз больше, чем П2. Если на примере котлет :) - в котлете может быть 10 грамм мяса и 90 хлеба, а может и 50 на 50. Но состав - всегда один: мясо и хлеб. А вот соотношение в каждом конкретном случае будет разным. У пользователя при вводе им данных в приложении-клиенте надо будет спросить состав, и конкретный экземпляр составного продукта будет помещен в другую таблицу (с указанием соотношения). Итого имеем: таблица ComplexProd лишь описывает состав сложного продукта. Реальный же состав помещается в другую таблицу. Вся прооблема в том, что в таблице ComplexProd хранятся не однотипные шаблоны, а разнотипные :( По сути - таблица описывает лишь состав разных типов составных продуктов. Но каждый составной продукт обрабатывается по-разному, т.е. для следующего составного продукта надо будет знать не соотношение сырья в нем, а температуру.
И вопрос такой: как правильно будет реализовать обработку типов составных продуктов - вынести полностью в клиент? Т.к. типов составных продуктов мало (не более 5) и все они заранее 100% известны (новые добавляться точно не будут), то такой вариант имеет место быть. Но как-то это нехорошо - выносить в клиент :( К сожалению, других вариантов я придумать так и не смог.
Подскажите, пожалуйста, может, я пытаюсь изобрести велик и все уже давно делается по-другому?
Заране большое спасибо!
...
Рейтинг: 0 / 0
Хранение в базе шаблонов, а обработка - приложением(+)
    #33165238
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Прежде всего посоветовал бы уточнить наименования таблиц так, чтобы они соответствовали смыслу отдельной строки таблицы.
ComplexProdType[s] вместо ComplexProd,
ComplexProdTypeComponent[s] вместо ComplexProdContent т.к. строка - про один компонент одного продукта.
Потому что содержанием (структурой рецептуры) правильнее назвать набор компонент для данного продукта - т.е. выборку из таблицы.
Такие наименования облегчат формулирование и обсуждение бизнес-правил и предотвратят недоразумения.

Перечень свойств, характерных для того или иного типа продукта лучше хранить в словаре, с тем чтобы клиент настраивался на этот список.

Отбражение свойств на поля таблицы по горизонтали или вертикали действительно многократно обсуждалось, поищите.
...
Рейтинг: 0 / 0
Хранение в базе шаблонов, а обработка - приложением(+)
    #33165265
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По умному это называется BOM (Bill of Materials)
По простому - комплект. Одно из фундаментальных понятий в автоматизации производства. Производство - одна из самых сложных тем в авт-ции предприятий.
Идеального рецепта Вам никто не даст, т.к. его не существует.
При работе с комплектами почти неизбежно применение итераций, т.к. комплекты в общем случае многоуровневые, причём один и тот же компонент может неявно присутствовать в одном комплекте множество раз. Предствьте для примера собранный двигатель и гайку М8, которая используется в 20 агрегатах дригателя, каждый из которых это тоже комплект. Учтите что в комплекте можно учитывать не только кол-во сырья, но и нематериальные понятия: время, кВт/часы, воду, зарплату и т.п. Это может пригодиться при расчёте и оптимизации себестоимости и получения структуры затрат.

Тут нужно серьёзное, продуманное Т.З. Не торопитесь писать код, иначе всё время будете переписывать.
...
Рейтинг: 0 / 0
Хранение в базе шаблонов, а обработка - приложением(+)
    #33165316
Kezya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
То ModelR: Спасибо, я что-то на название таблиц внимания не обратил, конечно переименую :(
Насчет многократного вложение - у меня такого нет. Вероятно, у меня наипростейший вариант автоматизации :) Всего 4 типа шаблонов, у каждого - по 2-3 свойства. Алгоритм такой: пользователь в приложении выбирает тип шаблона, я у него спрашиваю параметры и конкретный экземпляр уже добавляется в другую таблицу (таблица имеет внешний ключ на тип шаблона и параметры шаблона). Проблема еще в том, что в приложении под каждый тип шаблона должна быть своя форма. Она не универсальна. Причем для 2-х типов шаблонов надо выбрать вспомогательные данные из справочных таблиц, а для других 2-х - спросить данные у пользователя
...
Рейтинг: 0 / 0
Хранение в базе шаблонов, а обработка - приложением(+)
    #33165550
Kezya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как правильно должен реализовываться ввод данных для разных типов шаблонов? Повесить на каждый тип какой-то осмысленный идентификатор и в программе его анализировать?
...
Рейтинг: 0 / 0
Хранение в базе шаблонов, а обработка - приложением(+)
    #33165959
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНасчет многократного вложение - у меня такого нет
Это пока нет. Что будет завтра Вы не можете знать, поэтому старайтесь делать универсальнее. Научитесь предугадывать "на шаг вперёд", но не усложняйте. :)
Например типы шаблонов надо продумать так, чтобы обрабатывать их одной формой и одной процедурой на сервере. Нужны ли вообще разные типы ? Не есть ли такое решение напрасно надуманным ? Может просто придумать набор фильтров для разных случаев ?

"На вещи нужно смотреть ширше" (с) Напарник

ЗЫ: Вы же не собираетесь на этом месте всю жизнь сидеть. :)
...
Рейтинг: 0 / 0
Хранение в базе шаблонов, а обработка - приложением(+)
    #33166403
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KezyaКак правильно должен реализовываться ввод данных для разных типов шаблонов? Повесить на каждый тип какой-то осмысленный идентификатор и в программе его анализировать?Ну это уже про Delphi или что у вас на клиенте. Со стороны базы - если используется какой-то универсальный движок форм, то параметры настройки формы для каждого типа также никто не мешает хранить в базе в привязке к этому типу.
...
Рейтинг: 0 / 0
Хранение в базе шаблонов, а обработка - приложением(+)
    #33166501
Kezya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Клиент на VisualC++
...
Рейтинг: 0 / 0
Хранение в базе шаблонов, а обработка - приложением(+)
    #33166695
Kezya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А стоит ради 4 типов городить столько всего? Если повесить на каждый тип - идентификатор и в приложении по нему уже обрабатывать. Да, не очень хорошо выносить обработку в приложение, но в данном случае ради 4 разных объектов - может, не так уж и плохо?
...
Рейтинг: 0 / 0
Хранение в базе шаблонов, а обработка - приложением(+)
    #33170111
Kezya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вобщем, есть такой вариант: т.к. всего сущестувет 4 типа шаблонов (сущностей с частично одинаковыми атрибутами), то на каждый экземпляр шаблона - будет своя таблица, в которую они и будут добавляться с уже вполне конкретными параметрами. Итого получим 4 таблицы с данными. У каждой таблицы будет определенный идентификатор (справочный), который будет определять, во-первых, саму таблицу и, во-вторых, описывать шаблон (определять тип шаблона). Из каждой таблицы данные уже будут записывать в общую таблицу экземпляров, которая будет содержать только внешний ключ на любую из 4-х таблиц и справочный идентификатор, который и будет определять - из какой таблицы эти данные.
Поискал на форуме, вроде подобные варианты предлагались, попробую сделать так. С большим желанием приму критику и пожелания :) Если есть необходимость, могу выложить схему.
Всем еще раз спасибо за советы.
...
Рейтинг: 0 / 0
Хранение в базе шаблонов, а обработка - приложением(+)
    #33176832
panu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пробую решать сходную проблему со строго типизированными и различными сущностями данных,
спасибо за поднятый вопрос!!!
понаблюдаю за развитием событий

С уважением
Александр Плотников.
...
Рейтинг: 0 / 0
11 сообщений из 11, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Хранение в базе шаблонов, а обработка - приложением(+)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]