Lotsia PLM: Форум по семейству систем PLM/PDM/TDM/ERP/Workflow

Не далее как позавчера ко мне обратилась gali и спрашивала как реализовать структуру под журналы
-сделать максимально наполненный обобщенный объект ОДНОГО типа и из него создавать разные по наполненности журналы
или
-сделать направленные объекты РАЗНОГО типа учитывающие специфику того или иного журнала и работать с ними
я конечно поездил по ушам как обычно но к консенсусу мы не пришли
и вот сегодня уже перед нами встала подобная задача но применительно к Анкетам по семинарам
т.е. семинары разные Анкеты разные но в тоже время пересекающиеся между собой по информации на 50 %

расскажите как вы решали подобные задачи?
сделать ОДИН БОЛЬШОЙ общий тип объекта или сделать МНОГО МАЛЕНЬКИХ целевых типов объектов???
и плюс ко всему этому учитывая создание в дальнейшем простых и скоростных отчетов а также визуальную осмысленность и наполненность каждого из Журналов/Анкет отдельно

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

вообще, вариант с несколькими типами позволит более гибко настраивать формы, действия и отчеты, и работать будет быстрее. но в случае большого объема одинаковой информации у разных типов администратору придется вносить одни и те же изменения несколько раз. но это проще, чем пытаться втиснуть в одну форму несколько разных интерфейсов
вот такие мысли...

это понятно- но
- информация объектов на 50% общая
- представление информации на формах объектов - вообще практически одинаковое (отличие в заголовках)

и наверно все-таки лучше иметь общий универсальный тип который содержит
1- конкретные смысловые атрибуты
2- информационные атрибуты для классификации журнала/анкеты
3- и допустим по 10 обобщенных (без названий) числовых атрибутов, 10 таких же строковых + 5 таких же дата/время

это позволит в зависимости от значений информационных атрибутов вызывать из одной и той же формы разные действия для заполнения одних и тех же обобщенных атрибутов
и при анализе данных - дополнительный Select по одному/двум информационным атрибутам не должен занять много времени

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

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