создать систему для отслеживания дат предстоящего технического обслуживания спецтехники на предприятии, управление и планирование состояния техники на определенную дату

[taras-proger77]

Гибкость системы заключается в том, что её может настраивать кто угодно от пользователя до админа, но за исключением как раз разработчика. Если это правило не соблюдается, система не гибкая. Тем более если оно соблюдается точностью до наоборот. Но пользователи не имеют полномочий для части настроек, админ не имеет данных для другой части настроек, а разработчик вообще не знает, как оно должно быть настроено, так как ему не удосужились сообщить это конкретику. Если разработчику приходится сообщать конкретные решения хоть по одной настройке, системе не гибкая. А у Вас гибкость в условии. Вам нужно нечто, базоданообразное. Но если создать просто БД, то она не будет сама проверять текущую дату и не будет автоматически выполнять никаких действий по календарю. Поэтому СУБД + ещё два приложения. Разработайте нормальную форму БД со всеми таблицами и связями между ними. Или наведите на неё разработчиков, для этого придётся структуру БД описать своими словами. Как понимаете, так и пишите. Но никакого добавления параметра. Добавляться должны двигатели, насосы, генераторы и прочие агрегаты. И сами машины. Для каждой машины и агрегата вводится его тип, но уже не в программерском значении, а в обычном. И все остальные атрибуты. Атрибуты – это те же параметры, но по-базодановски. Всё вводится в это второе приложение, а оно уже добавляет в базу. А третье приложение регулярно проверяет базу, если у чего-то подходит срок, то оправляется сообщение кому надо. Как? Это уже Вам решать. Хоть письма пусть печатаются. Или вывешиваемые с утра на проходной списки. Или голосовой робот обзванивает пользователей. Или экран повесьте там, где все должны будут каждый день читать. Или по электронной почте. Или в месенджер, а за каждым пользователем закрепить комп, за которым он в определённое время каждый день должен сидеть. Или просто в динамик сервера. Или любым другим способом. При добавлении нового типа агрегата (в обычном смысле) вводится его регламентный срок. При добавлении нового типа машины (в обычном смысле) вводится её регламентный срок. При добавлении новой машины определённого типа (в обычном смысле) записи в таблицах «машина» и «тип машины» связываются уже тем, что поле «тип машины» заполнено в обеих одинаково. При добавлении нового двигателя записи в таблицах «машина» и «двигатель» связываются тем, что в обеих одинаково заполнено поле «номер машины». Поле – это то, в чём хранится атрибут и во что вводится значение атрибута. В таблице «тип машины» указано количество двигателей. Но БД не поддерживает связь 2 к 1, есть только 1 к 1, 1 ко многим и многие ко многим. Поэтому СУБД не сможет сама проверить, сколько должно быть двигателей, а о каком количестве внесена информация. А специализированное приложение для ввода данных в БД при заполнении поля «тип машины» читает количество двигателей, а потом не даст закрыть окно для добавления машины, пока с ней не будет связано ровно столько двигателей, сколько должно быть, да ещё и сообщит о причине на закрытия окна. А при связывании лишнего двигателя это же приложение проверит тип машины и прочитает, сколько у неё всего двигателей, после этого сообщит, что на эту машину все двигатели уже добавлены. Вот если потом появится нужда добавлять в базу агрегаты нового класса, для которого не разработан ни список атрибутов, ни структура связей с другими таблицами, тогда будет проблема. А тупое количество проблемой не является, с ним ещё в прошлом веке придумано что делать. И не мной.

[MI2]

Сообщение от taras-proger77

А зачем им добавлять параметр? Добавить надо объект и связать его с другим объектом. Есть объект «машина», есть объект «левый двигатель», есть объект «правый двигатель», добавляем все три объекта, каждому указываем тип и связываем их. А в каждом типе уже есть все нужные параметры, вводим их значения, некоторые параметры объектов типа «МАШИНА» указывают на пользователя.

В каждом типе разный набор параметров. В этом и проблема.. высылаю схематичное изображение сути проблемы.

[MI2]

Сообщение от taras-proger77

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

Спасибо. Не увидела сразу Вашего ответа

[ViktorR]

К вопросу об атрибутах.
Серийный номер.
Серийные номера на деталях могут и отсутствовать. Необходимо все поступающие в оборот объекты подвергать учёту. Должен быть разработан регламент учёта, в котором должны быть описаны все процедуры и формы.
Нельзя принести с улицы деталь и воткнуть её в изделие.
При выполнении операций по учёту необходимо предусмотреть собственный вариант клеймения. Существующие на деталях серийные номера являются только дополнительным идентификатором, и только.

При поступлении детали на склад заполняются определённые формы. При получении детали со склада должен быть оформлен акт ввода, в котором дата ввода в эксплуатацию должна стоять.
Мне непонятно, как может возникнуть ситуация, при которой у детали нет даты ввода в эксплуатацию. Это грубое нарушение регламента.
Изделие состоит из компонент, которые описаны карточками учёта и связаны между собой ссылками. Программный модуль может регулярно проверять все связанные карточки и критически реагировать на важные, помеченные специальным образом.
Как ранее и говорил, входной учёт ведут одни люди, контроль регламентных работ делают вторые, сами регламентные работы выполняют - третьи.
Проводят документы по учёту - бухгалтера, проводят документы по регламентным работам руководители, ...
После выполнения тех. регламента составляется акт и данные из него попадают в соответствующую карточку детали...