mirПопробуйте все же не полностью на EAV переходить, а делать таблицы с базовым набором полей (даже с запасом), а дополнительные, динамически добавляемые поля уже хранить в отдельной структуре.


Я ту немного это дело проанализировал - часто невозможно классифицировать сущности. Следовательно, в форме ЭАВ надо бы хранить атрибуты сущностей. А вот атрибуты отношений почти не меняются и частота доступа к ним большая, да и вся логика программы обычно на отношених. Тут надо все держать в жестких таблицах.

Bogdanov Andrey mirА что, поля добавляет пользователь в ран-тайме? Тада конечно. Но я говорил о другом случае, когда это -- задача административного характера.
Ну если атрибуты плодятся конечным пользователембезо всякого контроля, то тогда, конечно, лучше EAV использовать. В моей практике атрибуты добавлялись все-таки не конечными пользователями, а особо одаренными их представителями - аналитиками и настройщиками. И эти атрибуты были не просто "свалкой" информации, а играли какую-то роль в бизнес-процессе.

Аналитики и настройщики такие же пользователи.

Bogdanov Andrey Сахават Юсифов
Аналитики и настройщики такие же пользователи.

Ну все-таки не совсем "такие же".
Эти люди обепечивают технологию работы и использования системы в работе. И посему имеют дело не с отдельными экземплярами, а с группами экземпляров. Простые же пользователи (операторы) работают именно с отдельными экземплярами. Так вот если, модификацией атрибутики занимаются первые, то делают они для целых групп (классов) объектов. Ну а если модифицировать атрибутику должны вторые, то это значит, что собственный набор атрибутов будет у каждого объекта. Соответственно и способ реализации требуется разный.
Наример, технолог может решить, что в накладной надо указывать скажем ФИО водителя - он добавит новое поле и это поле будет у всех накладных. Другое дело, если оператор вдруг решил сам добавить в документ какую-то дополнительную информацию.

Потому и есть разделение. Атрибуты на уровне типа вводят одни, а на уровне объекта другие (права).
Т.е. - можно добавить "Цвет" типу "Материал", тогда при генерации объекта всегда будет предложено заполнить значение "Цвет". Но оператор может послать это дело и просто удалить "цвет" у конкретного объекта и/или добавить атрибут "процент сырости" который в списке атрибутов типа не значится, но имеется в домене атрибутов (доступ конечно тоже по правам).

Bogdanov Andrey
PS. Я пока никак не могу представить себе приложение в котором создание произвольных атрибутов операторами востребовано. Хотя вполне допускаю, что мне просто не приходилось с таким сталкиваться.

Да возмите, например, самый такой востребованный справочник - справочник материалов и ПКИ (или там как говорят "Номенклатурные позиции").

У "Доска" - "материал", "ширина", "длина", "высота", "коэффициент сырости"...
У "Краски" - "тип", "цвет",..
У "Двигателя" - "мощность",..
у "Коробки" - "передаточное число",..
у "Штаны" - "количество карманов"

Когда мы это дело только учитываем, то эти атрибуты вроде и не нужны.
Но, когда мы собираемся это дела производить, получается совсем другой коленкор.
Если все это объединить, то получится справочник с сотнями атрибутов. А если не объединить, то сотни справочников.

Bogdanov Andrey Сахават Юсифов
Да возмите, например, самый такой востребованный справочник - справочник материалов и ПКИ (или там как говорят "Номенклатурные позиции").

У "Доска" - "материал", "ширина", "длина", "высота", "коэффициент сырости"...
У "Краски" - "тип", "цвет",..
У "Двигателя" - "мощность",..
у "Коробки" - "передаточное число",..
у "Штаны" - "количество карманов"

Когда мы это дело только учитываем, то эти атрибуты вроде и не нужны.
Но, когда мы собираемся это дела производить, получается совсем другой коленкор.
Если все это объединить, то получится справочник с сотнями атрибутов. А если не объединить, то сотни справочников.

Замечательно. Вы сами привели типизацию своих объектов по количеству используемых атрибутов. Имеем тип "Штаны" с такими-то атрибутами, тип "Коробки" - с другими. Для разных типов - разные таблицы хранения атрибутов. Не вижу сложностей. Если вы собираетесь как-то использовать в системе эти атрибуты, то вам все-равно придется научится их программно идентифицировать. Если же они хранятся просто так, то все это можно назвать одним атрибутом "Описание изделия".

Да этих типов - сотни, если не тысячи.

mcureenab Bogdanov AndreyДля разных типов - разные таблицы хранения атрибутов.

Это не единственный способ. Можно разнотипные объекты хранить в одной таблице и даже под группу разных атрибутов использовать одно поле. Другое дело, насколько удобно будет работать с таким хашем. Кроме того процедура определения такой таблицы весьма нетривиальная. Так что проще всего под Штаны и Двигатели создавать разные таблицы, а слить их до кучи можно всегда.


Мы вообще не знаем, будут там "штаны" или "Двигатель" или нет.
Как только решили что вмество "Ручки для толкания :)" будем использовать "Двигатель" появляется нужда в двигательях.
Неужто, сразу надо создать новую таблицу?


[quot mcureenab]
Есть ещё момент, когда прекратить классификацию. Двигатели бывают электрические, паровые, внутреннего сгорания, гужевые и т.д.:o). Далее дизельные, карбюраторные, инжекторные. Турбинные или поршневые. Коллекторные, асинхронные, и д.р.

Положим, у нас есть паровые двигатели, стоит ли создавать подклассы Турбинные, Поршневые, Реактивные или лучше в классе Паровых двигателей определить атрибут принцип действия, который будет являться дискриминатором типа? Если использовать дискриминатор, то мы приходим к тому, что в одной таблице фактически будут храниться разнотипные объекты с общим суперклассом. Сегодня нам достаточно знать о двигателях только принцип действия, завтра нужно будет знать количество и размеры цилиндров, материал турбины, диаметр сопла, расход пара и т.д. Тут напрашивается создание отдельных таблиц и миграция данных. Или использовать "Описание изделия".
[quot mcureenab]

А почему мы должны прекращать классификацию? Просто надо дать возможность ввести новый классификатор или подклассы в существующий.
Что Вы подразумевате под "Описание изделия"? Изделие имеет собственные атрибуты, а спецификации собственные. Некоторые атрибуты изделия наследуются от спецификаций, некоторые от процесса изготовления, некоторые приобретенные.

Я вот пытаюсь сейчас такую вещь сварганить.

mcureenab Сахават ЮсифовА почему мы должны прекращать классификацию? Просто надо дать возможность ввести новый классификатор или подклассы в существующий.

классификатор = атрибут или новое значение в домене?

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


Классификатор сам по себе. :) У них свои атрибуты из домена атрибутов.
Классификация - это как бы добавить атрибуты к существующим объектам скопом.
Типа множественнного наследования. Основные атрибуты от типа + классификационные, мягкие атрибуты. Типы и классификаторы могут быть агрегированы. Агрегатные объекты проверяются на соответствующий агрегатный тип. А агрегаты классификационные - дело пользователя.
Классификаторы - польностью дело пользователя. Да и типы (кроме некторых для данной предметной области.)

Сахават ЮсифовЧто Вы подразумевате под "Описание изделия"? Изделие имеет собственные атрибуты, а спецификации собственные. Некоторые атрибуты изделия наследуются от спецификаций, некоторые от процесса изготовления, некоторые приобретенные.

"Описание изделия" - атрибут реляционной БД, колонка в таблице. Для наполнения колонки можно использовать формат XML, где каждому тэгу соответствует некоторый атрибут или их группа.
Принципы наследования атрибутов от других объектов определяются на уровне приложения.
Нужно решить проблему поиска готовых типов, чтобы пользователю каждый раз не приходилось конструировать новый тип с нуля перебирая все существующие домены и оценивая их пригодность для описания изделия.
Время от времени придётся причёсывать БД, чтобы исключить опечатки, и прочие ошибки.[/quot]

Ну по хорошему все это будет использовано как часть проги описывающий предметнюю область. Что бы многократно это не делать решил выделить в отдельную часть описания предприятия.

mcureenab Сахават ЮсифовНу по хорошему все это будет использовано как часть проги описывающий предметнюю область. Что бы многократно это не делать решил выделить в отдельную часть описания предприятия.

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

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

Сахават Юсифов mcureenab Сахават ЮсифовНу по хорошему все это будет использовано как часть проги описывающий предметнюю область. Что бы многократно это не делать решил выделить в отдельную часть описания предприятия.

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

Разработчика нормативных процессов.
А дальше будет автогенерация сети возможных процесов и (при поступлении заказа на производство) и выбор оптимальной подсети для привязка процессов к реальным.
Ресурсам :)

mcureenabТипа Workflow?

Значит тебя "Штаны" и "Двигатели" интересуют не нак объекты учета, а как спецификации? Тогда конечно, создавать таблицу "Штаны" нет никакого смысла, ведь по идее они все одинаковые.
Типа, нужна партия товара "Штаны галифе, арт. 12345". В систему заносим спецификацию и запускаем её в workflow. Вопрос, надо ли детализировать что такое "Штаны галифе, арт. 12345", или в пакете технологической документации это уже есть? Видимо, имеет смысл описать из каких деталей состоят штаны, а детали из материалов, указать технологические операции по производству заказу материалов и производству деталей. В итоге от абстрактных атрибутов чего то там непонятного, мы приходим к вполне понятным потокам "Специфкаций изделий", и "Специфкаций операций" в самом общем смысле.
Когда дело дойдёт до учета конкретных изделий, тогда можно подумать о создании соответствующих таблиц, но если экземпляры изделий отличаются только №№ партий, то можно учитывать "Партии" в общем смысле.

Оттуда иду. :)