@makem

Нужно написать базу главного инженера по оборудованию для предприятия пищевой промышленности . В ней должны быть отражены таие понятия как
( перечисляю по уровню вложенности понятий):
1. Цеха
2. Участки
3. Производственные компоненты
3.1 Машины
3.2 Узлы
3.3 Подузлы
3.4 Механизмы
3.5 Детали
Это что касается структуры производственного комплекса.
Далее необходимо определеить следующие сущности:
- ЗИП (запасные части и принадлежности)
- Ремонт (производственные компоненты находящиеся в ремонте)
- Утиль (производственные компоненты вышедшие из строя, возможно включают в себя ещё рабочие подкомпоненты)
- Заказы (здесь аккумулируется информация о заказах компонентов сторонним производителям и поставщикам)

Понятно, что база не из простых. К тому же ещё добавляется поиск и генерация отчетов, прослеживание истории для каждого компонента и т.д.

Может кто видел или знает как организовать такую махину ?...

Буду рад Вашим отзывам и обсуждению этой темы.

0

TSergey

Интересно, какого ответа ты ждешь? Готового решения со структурой БД и прогой? Вряд ли дождешься. Задача действительно непростая (но и не архисложная) и решение стоит денюжков, и немалых наверное.
Если надо писать - пиши. Будут конкретные вопросы - задавай. А так...

Можно и готовое поискать. Наверняка подобные подсистемы есть в готовых КИСах. Но, опять же, денюжки нужны.

@makem

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

В принципе структура БД уже построена. Есть некоторые концептуальные вопросы касаемые истории транзакций и компонентной модели производственного комплекса. Но всегда хочется знать мнение профессионала ( себя таковым пока не считаю ). Если будет интересно - выложу и распишу.

0

Vsh

нет одной фундаметнальной вещи - для чего эта база, что это будет

в вашем описании это просто справочник
ЗЫ
если у вас нет опыта создания сколь либо сложной подобной системы, то эту задачу вы провалите со 100% вероятностью

@makem

Спасибо на добром слове :-)

Вообще, если говорить откровенно, о конечной цели разрабатываемого продукта не знает даже тот, для кого все это делается. Он витает в облаках )). Но кое что уже конкретизировал. Будущая система призвана помочь помочь ему в решении повседневных задач и пока должна:
1. Содержать каталог производственных компонентов данного предприятия ( на производстве, в Зипе, в ремонте и т.д.)
2. Для каждого компонента владеть информацией о его жизненном цикле.
3. Позволять вносить и отслеживать текущее состояние заказов новых компонент. (уже реализовано)
4. Предоставлять удобные средства для поиска и анализа хранимой информации
5. И в конце концов быть понятной и легкой в использовании. О надежности должен естественно позаботиться я.

На данный момент пока все требования.

0

TSergey

Тут еще один подводный камешек есть. Кто будет вести эту БД? Смотреть понятно - ГИ, а вот заводить кто? Я помнится лет 10 назад, еще на Клиппере, делал планово-предупредительный ремонт. Механикам 'ну по зарез надо было' графики получать на компьютере. 'Почти' сделал (в тесте работало), надо было заводить инфу (завод в 3000 человек - не маленький). И тут почему то, пыл заказчиков пломенял свой знак на противоположный. Т.е. результаты то нам нужны, но вести базу у нас времени нет.

Еще, поддержу Vsh. На самом деле, если 'о конечной цели разрабатываемого продукта не знает даже тот, для кого все это делается' то перспектива закончить проект в обозримом будущем стремится к нулю. Даже если ты напишешь то что описал, то потыкает ГИ по кнопкам неделю-другую и надоест ему это дело, там же не девки голые, а станки - чего на них смотреть то.

Vsh

Задача должна быть поставлена четко
-в результате мы должны получить то и то, в таком и таком виде (образец прилагается), по таким и таким позициям (спецификация прилагается)
-в дальнейшем система должна быть доработана (куда и как - документ прилагается)

поймите, вам говорят нечто вроде - сделайте мне классную программу,
при такой постановке вопроса что бы вы не сделали будет не то

1 добейтесь четкой постановки задачи, с перечнем входных и выходных документов (и описанием их связи)
2 вам НЕОБХОДИМ организационный план внедрения и эксплуатации (иначе то что вы напишите с большой вероятностью никуда не пойдет (например скажут -Ах, мне еще и операторов для этого нанимать, зарплаты им каждый месяц платить!))

@makem

Мои превеликие спасибки за поддержку и сочувствие ;-). По большому счету я не думаю что все так плохо, в любом случае система уже 'почти готова'. Все таки итерационный подход дает свои плоды. Сотворил операцию - на, пробуй. После долгих полемик и многоярусного мата привожу 'клиента' к пониманию сути вещей, после чего он день-другой пробирует на тестовых данных, выносит свои соображения и в результате я корректирую систему в соответствии с его пожеланиями. На каждую итерацию уходит почти неделя. В результате 'клиент' просвещается, если так можно сказать, потихоньку вникает в структуру базы, и чуть ли уже не владеет SQL . И мне хорошо и ему приятно. Несколько модулей уже работают чем невероятно радуют последнего. Вот таким образом все и строится.

0