Здравствуйте.
Недавно решил заняться выдумкой структуры базы, нового что-то вряд ли придумал, поэтому хотелось бы узнать мнения. СУБД оракл 9 версия.
Идея в следующем: хочется сделать гибрид еав и рм для использования плюсов обоих подходов и избежать минусы по максимуму.
Предполагаются следующие таблицы в упрощенном варианте
1. сущности: наименование сущности (имя таблицы) (пк), ключевые поля
2. атрибуты: ид сущности (пк1 фк на сущности), наименование атрибута (имя столбца в таблице)(пк2), тип (строка, число, дата, мб какой-нибудь лоб), табличный атрибут или нет
3. значения атрибутов (еав таблица): сущность (пк1), атрибут (пк2), ид объекта1 (пк3), ид объекта2 (пк4), значение (не уникальный индекс вместе с сущностью и атрибутом)
Для каждого объекта будет создана реляционная таблица с набором обязательных, необходимых для осуществления поиска данных, фк (табличные атрибуты), а также доп. атрибуты которые могут быть или не быть заполнены, поиск по которым не так важен (хотя и возможен), информация о родительских объектах (если она отличается от родителя) и т.д.
Т.е. будут заполняться таблицы сущностей и атрибутов сущностей, табличные значения будут храниться в таблице, доп. значения будут храниться в таблице еав.
Таблиц еав предполагается несколько, разбиты по типам: число, дата, строка (для экономии места задумано 6 таблиц для строк, т.к. считаю не резонно под значения, допустим ИНН, забивать 4000 символов).
Долго решал, как быть с идентификаторами объектов, стандартная модель еав предполагает уникальный ид для всех объектов, рм же позволяет делать сложные ид наделенные смыслом состоящие из нескольких полей. Возьмем за объект сущность у нее ид наименование сущности, можно сделать ид цифру и тогда мы будем иметь не совсем нужный ид не дающий смысловой нагрузки, к которому нельзя привязаться в запросах без обращения к таблице сущностей. Возьмем за объект атрибут его ид составной наименования сущности и атрибута, опять же если сделаем цифровой ид, получится чтобы получить допустим значение атрибута зная сущность атрибут и ид объекта нужно сделать запрос к таблице сущностей, сделать запрос к таблице атрибутов, сделать запрос к таблице значений итого 3 запроса заместо одного. Другой пример существует объект, у которого есть атрибут пользователь, который что-нибудь сделал с этим объектом, логин это не только уникальный ид но и много говорящий (у нас на работе в него зашивают не только ФИО человека, но и принадлежность к филиалу, и версию программы в которой он работает, и это не говоря уже о технических пользователях по которым по логину видно для чего вообще он объект трогал) если я буду хранить цифровой ид в таблице, мне необходимо будет постоянно делать запросы на получение этого логина, конечно я еще буду получать и другую полезную инфу этими запросами, но она может оказаться и не нужна. В итоге получается, что для еав нужно ограниченное кол-во ид объекта, а для рм наоборот ид может быть несколько. Взвесив и то и другое, решил завязаться на два ид и соответственно расширить таблицу еав, если у сущности один ключевой атрибут буду писать нулл в ид2. Два ид для многого хватит, а если где не хватит можно перейти на обобщающий цифровой код (получается, не всегда он будет нужен).
Конечно, думал и над другим решением, можно сделать внешний и внутренний ключ, внешний ключ будет цифровой и уникальный для всех объектов, а внутренний будет осмысленный. Тогда таблицы можно будет связывать как по внешнему ключу, так и по внутреннему, а в таблице еав будет использоваться внешний ключ.
Обработка объектов. Сделал пакет который делает стандартные дмл операции над объектами динамически, т.е. получает объект, делает новый, удаляет и изменяет. Загруженный объект будет хранится в пл\скл таблице объект(сущность)(ид1)(ид2).тип(атрибут), и обновляться будет только при изменении. С этим тоже есть вопрос, начиная хранить данные в памяти, будут уменьшены кол-во запросов. К примеру, есть сущность и есть родительская сущность, для каждого объекта нужно выводить инфу по родителю, итого, если пользователь запрашивает данные из базы, придется для каждого объекта сделать запрос, хотя может всего один родитель используется для этих данных, проще информацию запомнить и выкидывать ее как можно быстрее. С одной стороны это увеличит скорость и, по опыту знаю, что может увеличить сильно. С другой стороны расплачиваться придется ресурсами, вот здесь и встает вопрос, сильные ли будут затраты, конечно все зависит от кол-ва пользователей и кол-вом получаемых данных, но можно ли примерно сказать для средней системы?
Были вариации грузить в память не все, а только самое необходимое как вариант.
Оставлять в памяти планируется только для интерфейсов, для расчетов все можно чистить после обработки.
Также встает проблема еав с целостностью, выше я написал, что фк хотелось бы сделать табличным атрибутом, но это не всегда будет нужно, бывают и не очень полезные фк, которые будут заполняться для 1 объекта из 100, а то и менее нужные, но все равно фк. С одной стороны можно и оставить его в основной таблице, а можно скинуть в еав таблицу. Есть ли какие-нибудь пути к улучшению целостности? Пока для меня проблема при одновременном удалении родителя и вставки ребенка, возможно нужно лочить родителя пока идет вставка, но могут возникнуть дедлоки, да и бесполезно вставлять запись если через секунду она будет удалена.
Вроде пока все, а то и так много понаписал, заранее спасибо за комментарии

по порядку
astonЭто что, очередной мегапроект из серии "вся система в 3-х табличках с автоматически формируемым интерфейсом"?
нет, в самом начале написал что это гибрид, еав хотелось бы использовать как полезное универсальное дополнение.
И пока речь идет о хранении данных, а не об интерфейсе, конечно интерфейс предполагается и вполне возможно что динамический
ToshikПока дочитаешь до конца выпускается из виду начало. Вы сделайте картинку структуры, а мы уж с удовольствием покритикуем.
В каком виде хотелось бы увидеть? Пока структура сама в задумке и частичной реализации. Просто если нарисую текущую структуру без сущностей будет опять похоже на чистый еав, что будет сбивать с толку.
guest_20040621Тифа, Вы занимаетесь абсолютной хренью. Ощущение, что Вы собрали весь мусор рунета.
Если честно не много читал по инету про структуры бд, читал в основном про чистые модели еав и рм, может и стоит почитать побольше, но где видел там все одно и тоже, либо стандарт и все говорят что нечего интересного либо еав и все говорят что "хрень", читать устаю
LSVЗадумка мож и неплохая..... но реализация будет...эээ..... (политкорректно) перегруженная и усложненная. Посему малоинтересная.
реализовать наоборот пытаюсь прозрачнее и как ниже написали что все по простому, хотя сверху описана только основа, сверху наложен многое типа универсального аудита, описание связей между объектами, наследование и др.
SokolNikеав абсолютная ерунда ( в связке с СКЛ серверем имею ввиду), можно использовать только для динамический атрибутов (и то по мере накопления статистики надо перевести в нормальную структуру). Главное ИМЕТЬ И УМЕТЬ работать с метаданными, в СКЛ серверах (я в основном с МС СКЛ работаю) их не так много, потому надо иметь свой репозитарий метаданных (допусти фиг поймешь из каких сущностей и связей состоит устойчивый бизнес объект, какие у него методы и события).
ОРМ в тепершнем виде полная фигня, это просто перевод структуры БД в структуры классов, а агрегирующие классы все равно ручками надо, значимые ассоциации и ссылочные перемещаны и т.д.
ну тут позвольте не согласиться что еав уж такая абсолютная ерунда. вернемся опять к сущности пользователь, в базе можно хранить сотни настроек для каждого пользователя, от запоминания папки из которой он грузит файлы до настройки печати документов. т.е. по вашему надо создать таблицу с несколькими сотнями полями и забивать в них настройки пользователей? при этом постояно добавлять туда новые при появлении каждой новой настройке? или сделать еав пользователь настройка значение?
и это не только пользователи, к примеру у платежного документа есть только для печати около 150 атрибутов (извиняюсь вспомнить точное кол-во не могу), а заполняется обычно в среднем 40%, отсюда вопрос зачем иметь 150 полей, если они не нужны (точнее нужны, но редко), или предложите разделять 1 единую сущность на 5-10 подсущностей и заполнять по мере необходимости, но по мне дак это не далеко от разделения на еав.

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

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

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

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

guest_20040621> чем описанное не подходит под метамодель общей системы?

Ничем. Это не метамодель.

видимо не так термин понимаю, можно ссылочку какую-нить где почитать можно? если не сложно