как разруливаете целостность в ЕАВ?
и насколько у вас ЕАВ?

KOT MATPOCKuHНа сколько я понимаю, EAB не предполагает целостности (в стандартном для БД понимании).
Соответственно, рулить пытаться можно руками и далеко не везде.
Например, для проверки корректности заполнения поля (из справочника) можно кодом проверить корректность.
При удалении записи из справочника - тоже можно пробежать по всем "аля связанным" таблицам и проверить наличие удаляемых данных.
Но, проверки типа NOT NULL реализовать не удастся, в силу специфики EAB. Возможны только корявые потуги.
Ну NULL там по определению не может быть. :)
А целостность я имею ввиду вот что - запретить "машине" состоять и "человека" и "яичницы".

guest_20040621> .

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

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

ChA...
Почти так и сделано

guest_20040621> ...
Получается, что ЕАВ жив. :)
Добавлю всякие ограничения, умолчания на свойствах, вычислимы свойства, агрегаты и т.д. и попробую протестить на больших объемах.
Если все будет ОК, то до пенсии больше не буду писать всяких гадостей, кроме алгоритмов предметной области.

guest_20040621,

Конечно, ЕАВ тут один из аспектов. Я подумываю поставить галочку (ЕАВ или плоская таблица) что бы пользователь сам выбрал способ хранения данных для системных (описанных в модели) свойств и внешних ключей) Но тут сложности, при изменении модели надо будет периодически "выпрямлять" БД по мере накопления изменений. Может это и не пригодится, надо бы протестировать, но сейчас занять визуализацией связей (там получаются циклы при навигации и т.д., которых надо обойти). воще эти циклы забодали. :(

_модguest_20040621Т. е. дополнительно к собственно классификаторамнужна дополнительная структура данных, которая описывала бы и сущности, и их атрибуты, и правила классификации.
Ну, собственно так и есть. Метаописание сущности содержит перечень ее атрибутов разных типов, в т.ч. и тип "ссылка на классификатор". Это описание используется и для отображения и для целостности и для навигации. При этом сами классификаторы не являются сущностями.
1. Может ли объект иметь (не иметь) свойство, которого нет (есть) в описании класса-шаблона этого объекта?
2. на какой стороне переварачиваете ЕАВ? (сервер, клиент). Все ли переварачиваете?
3. Как управляете навигацией? (Допустим, начиная с какого то узла дальше на форме не надо показывать релейшны, или надо показывать только указанные релейшны по всей глубине). Как с циклами в навигации? Как формируется паекль навигационный?
Эх, посмотреть бы рожу готовой проги. :)
4. Как с дополнительными экшнами? Это хранимки или программный код? Меняете прогу саму или есть механизм вызова внешнего кода?
...

Сахават Юсифов,
паекль = панель :)

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

YulkaУ Сахавата налицо смешение разных понятий «класс, тип» и дурная наследственность EAV c его недоопределенностью.

Сахават бы с удоволствием стер бы с словаря слова - класс, свойство, тип и т.д. Каждый понимает что хочет под этими словами.
На самом деле нет никаких классов. Класс - это шаблонное видение классифициующего под который кастируются реальные объекты.
В любом случае класс= (Имя, идентификатор) + {свойств для отбора объектов}. Это при классификации по существующим свойствам объектов. (Select * where имеется {свойств для отбора объектов})
Другой вид классификации - агрегирующий, классификатор является СВОЙСТВОМ для всех агрегрированных объектов, у которых изначально НЕТ такого свойства. Например Мои_Друзья(перечень идентификаторов классов и отдельных объектов).
Эти два вида классифицирующих объектов составляет единый навигационный классификатор со множеством классифицирующих входов.

Никогда в один классификатор не могут попасть элементы множеств с разной структурой (структурой – слово заезженное, тут в смысле «ступени», декартова произведения на множестве всех объектах-экземплярах).

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

Классификатор не дерево.

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

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

Отнощение такой же класс как и остальные. Единственное отличие - объекты этого класса не имеют осмысленного имени. Нельзя
ИД1,Работает1, чел1, цех1
ИД2,Работает2, чел2, цех2

Можно создать агрегирующий классифицирующий объект Документ и приписать к нему отношения. Т.е. ничем классификация отношений не отличается.

В принципе никто не мешает туда же «в классификацию» добавить и проекции по определенным элементам (например, состав объекта ДСЕ25 по отношению «Спецификация»), но их необходимо выделить атрибутивно, так как это тоже ни к каком смысле не подмножества, ну и имя отношения и роль в нем придется указать.


Проекция - динамическая классификация по свойству классификатора (свойства классификатора является фильтром в select. Любой узел графа классифицирующего является оператором Select.

Типы данных, свойства, объекты (экземпляры), классы это принципиально разные вещи, обращаться с ними надо по-разному. У Сахавата «тип» - это сборная солянка из всего, и отношение это сборная солянка из всего.

Это все одна и та же фигня с точки зрения возможности приведения в вид (ИД, Наименование).

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

Ну, прогеры привыкли, что есть класс "Color"и справочник "Едизм" с несколькими свойствами.
Короче, не расчищено. В топку такие конструкторы.

Чтобы EAV стала работоспособной, необходимо добавить более жесткие метаструктуры и навесить атрибутику на них, чтобы потом работать со всем правильно, а не складывать Сахавата и 52.

Дык, это дело прикладника, а не проги моей. Пусть опишет правильно. :)