Alexey RovdoВ соседних ветках это уже отмечалось, но выскажусь еще раз.
Мне кажется, что попытка втиснуть в реляционные структуры динамически изменяющуюся модель (причем без использования CREATE TABLE и пр.) обречена на провал. Реляционные СУБД просто не приспособлены для такого обращения. Разумеется, можно построить некие абстракции высокого уровня и впихнуть в них все необходимые данные, но ценой станет отказ от множества функций, предоставляемых именно реляционной СУБД. Т.е. по сути прийдется строить объектную СУБД поверх реляционной, что ИМХО просто лишено смысла. Зачем так надрываться, если есть собственно объектные СУБД, причем ориентированные именно на использование с динамически изменяющимися структурами данных?

Вы невнимательны:
авторсдается мне, что таковые построения существуют, и применительны к весьма неширокому кругу (кругам?) задач (назовем их "секретарскими"?),
Повторю, я не хочу хранить "объекты" в смысле ООП. Я хочу понять, каковы мои возможности в построении реляционной БД для хранения разнообразных до/переопределяемых сущностей. (нигде у меня не сказано про "наследование" и еще черт знает что). Более того, дергать криэйттаблы только затем, что у меня подвижная структура сущностей (и больше ничего) - это ли не надрыв? А вот я возьму и выйду за любые рамки по количеству таблиц/полей. И что тогда?

От чего и где отказываемся - это вопрос конкретной реализации "абстракции высокого уровня ", которые и хочется рассмотреть (и поковырять хотя бы виртуально пальцем), а, думается мне, не вопрос ИМХО-в.

"Надрываться" - в смысле зачем описывать некую область в свзязных абстракциях, и, тем более, сравнивать разные описания? Их продуктивность? - Хотя бы затем, чтобы поиметь опыт такого описания. До тех пор, пока не рассмотрена ни одна, пусть умозрительная реализация, как мы узнаем, действительно ли этот подход не стоит рассмотрения ни при каких условиях? Давайте и останемся в наших узких рамках.



А преимущества объектных БД в деле размещения динамически изменяемых структур данных можно рассмотреть и в другом месте - там где уже не один год меряются ИМХа-ми.

Alexey RovdoТак ведь тут вовсе не промежуточный случай предлагается разобрать, а самый что ни есть крайний. Да и в промежуточном случае (т.е. если в задаче есть и статические, и динамические структуры данных) строить объектную базу поверх реляционной на мой взгляд нерационально.
ну чё вы словами-тта кидаетесь? Хде сказано за объедки? За сущности базар идет. И токо за них. Не путайте красное с кислым. (встречается и сладкое и полусладкое).

Alexey Rovdo Имеет смысл просто использовать две базы и соответствующий инструментарий (в т.ч. и входящий в состав самих СУБД) для их связывания. Обычно именно так и поступают.

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


Еще раз! Просьба не базарить за объедкные БД. Не наследуем мы код. Не наследуем и не перекрываем и задач таких не ставим.
Мы узкую задачу посмотреть хочем.
Меж прочим.


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

Alexey Rovdo А вот ниже уже выясняется, что и крейт-таблы все-таки допустимы и статические данные все-таки какие-то есть.
Еще раз огромная просьба, свои домыслы и вымыслы обсуждать в в более приспособленном для этого месте. Тут сделана, признаюсь неудачная, попытка обсудить сугубо узкий вопрос - об отражении задачи о сохранении наперед не определенного набора сущностей с наперед не определенными атрибутами на жестко предопределенную структуру данных. Построить т.с. абстрактную модель именно этой, с позволенья сказать, "предметной области". И по возможности просмотреть, а в идеале - _систематизировать_ варианты (буде такие будут предложены). Но варианты именно такого отображения.

DogenP.S. По большому счету это все фигня, РСУБД внутри РСУБД. Имхо, может быть нужно только для построения перечней объектов с наперед неизвестным набором атрибутов.

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

Dogen "по наличию атрибута" у меня реализовано путем введения сущности "тип документа", а ей уже соответствует определенный набор атрибутов.
Набирать заранее неизвестный набор атрибутов для каждого документа мне нет нужды (ну если приперло создать уникальный документ - создайте для него новый тип, сиречь набор атрибутов). Это дисциплинирует.
Продолжаем колоться
Вот уже прорезалась табличка "тип документа" (или даже "тип сущности"?) + табличка "атрибуты сущности" - т.е. это описатели структуры (уже "юзерской") сущности. По ним, я так понимаю, вы интермордс вырисовываете для заполнения экземляра "документа" заданного вида. Так глядишь и раскрутим на более подробное раскрытие.

Сразу вопрос. "Тип документа" (сущности) у вас имеет какие либо иерархические причандалы? (Скажем просто - в качестве организации просмотра типов по дереву типов, а не для какого-нть наследия).


И (только тихо! не к ночи помянуто): забирались вы в реализацию "наследования" структур одним "типом документа" (в вашей терминоЛогии) от другого или нет? (не в смысле выкопирования описателя, от одного id к другому, а в смысле именно "наследования". Тилько шопотом (боюсь опять выскочат объектщики, тьфу на них). И нужно ли оно в таких вещах? - Понятно, что запросы, если описатель собирается просмотром по "дереву", усложнятся (вернее могут - "ит депендс"), а обычная для БД реализация "наследия" в смыле выкопирования атрибутов от одного "типа сущности" к другому пусть и не съекономит места в описателях (и не даст жесткости, т.е. даст свободу не иметь "потомку" ненужного добра), но не заставит заморачиваться просмотром всех "предков"). Или "наследование" структур тоже вполне реализуемо?

Dogen
Типы документов я наследовать один от другого не собираюсь, поскольку в нашем случае это будет полезно, но трудозатраты вряд ли окупятся. В будущем - может быть.
Разумный скепсис, но, с другой стороны, отсутствие опыта [попыток реализации] - это отсутствие опыта. Т.е. оценка трудозатрат не подкреплена реальными шишками от реальных грабель. - Я как раз на развилке в принятии решения. С одной стороны - казалось бы упрощается обновление наследуемых атрибутов при их редактировании в предке. Но только тех, которые не поимели конкретных значений в потомках (тут возникает проблема разруливания по логике - какие-то атрибуты должны иметь возможность перекрывать в потомке тип, заданный в предке, какие-то нет. Какие-то действия пользователя по настройке классификации типов _должны_ а) однозначно пытаться сменить тип атрибута и во всех потомках сущности ("CASCADE"), б) - какие-то только в тех, которые еще "не перекрыты явно" (не поимели своих строк в описателе) или не поимели _значений_ унаследованного типа (в этом случае - нужно будет "перекрывать" ("теневым образом" - разве что сообщив об этом) атрибуты потомков в процессе редактирования атрибута предка, в) какие-то должны иметь влияние только на текущий уровень классификации (т.е. все потомки не должны наследовать этого атрибута). Все то же самое, как легко заметить, можно и сделать с помощью выкопирования описателя объекта в его детей (и поиметь те же вопросы "теоретического" характера при переопределении атрибутного состава предка).

DogenНо честно говоря, намного проще написать процедуру копирования набора атрибутов одной сущности в новый такой набор.
чего проще - всобачить триггер на заимствование аттрибутов при создании потомка (+- для полной логической завязки - триггер на редактирование предка, но тут - сразу вопросы к логике - т.е надо оперделиться "что мы хотим поиметь").

Кстати, в некоем смысле то, что привел Alexey Rovdo описывает (частично) то, о чем говорите и Вы? Т.е. приблизительно та же завязка между типами и экземплярами? Правда самих значений ("расширенных") атрибутов я у него на схеме не вижу. Кажется - только ссылки?



2Alexey Rovdo:
Смотрю я на вашу схемку, и возникают у меня вопросы:

1. За что отвечают поля IsChilde и IsReplicated? Какой в них физ смысл (что за абстракции или логические связки промеж оных в них порылись?)

2. За что отвечает поле d_DocumentExtendedData.DataObjectID (d_DocumentExtendedData.Type - это кааца Fk к ID из aDoc....DataType) ? (если это дубликат d_Document.Type - то это то, о чем я думаю? Т.е. денормализация с целью поиметь нужные индексы в d_DocumentExtendedData ?) Или это ссылка на реализацию атрибута в какой-нть табличке значений? (если вы его находите не через GlobalID)
2.1 (того же типа вопрос и по ObjectTypeID)

3. Ну и т.п.




__
2All:
не видно особых альтернатив к набору абстракций, покрывающих "предметную область" (и даже к реализации). Пока только такой набор (грубо):
1. Сущности
2. Их сотав (описатели)
3. Экземпляры сущностей
+- 4. (вероятно по вкусу) - дублирование всего набора на сущности "блатного" типа "атрибут".

Нешто никто не делал иначе?

Спасибо за ответы.
Посмотрю еще. А пока:
Alexey Rovdo IsChild
Определяет тип атрибута (не забываем, что атрибутом может быть любая сущность), с точки зрения его самостоятельности. Есть атрибуты зависимые и независимые. Зависимые атрибуты (сущности) имеют "хозяина" (d_Global.Owner_id). Зависимые атрибуты (сущности) удаляются вместе со своим "хозяином". Поле IsChild анализируется только в момент вставки нового атрибута. После того, как атрибут (сущность) уже оказался в базе, определение его зависимости/независимости уже происходит по значению d_Global.Owner_id.

Немного не допонял.
т.е. вы обрабатываете следующую ситуацию (для простоты считаем что речь идет исключительно о "документах"): "Документ" + "Приложение к нему". (Когда приложение - тоже документ, но не живущий без "хозяина", и удаляемый вместе с ним. Причем оно может входить не более чем в один документ (иначе как рулить удалением? считать ссылки?). Если же ссылочный(сущностный) атрибут (некоего "хозяина") может входить во что угодно (справочный - например контрагенты с их структурой) то он неЧайлд?

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

Alexey Rovdo
Замечание: все, что лежит в таблицах с именами a_... фактически имеет отношение к бизнес-логике, а не к самим данным.

В моем случае это "логика интерпретирования вообще". Т.е. имеет прямое отношение к хранению типов и ("хранению") их интерпретации.
Alexey Rovdo

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

С этим ясно. Что-то в этом смысле мыслилось. Правда в некоторых случаях есть "предельная емкость".
Alexey Rovdo
IsHeritable
В данной схеме нет, но в отдельных случаях тоже использовал.
Если объекты могут объединяться в иерархию (например, в таблице d_Document есть поле parent_id, указывающее на документ-родитель), то атрибуты родительского объекта могут считаться и атрибутами всех принадлежащих им сущностей-потомков, а могут и не являться. Поле IsInherited как раз и определяет этот факт. Разумеется есть две стратегии поведения, которые выше уже и были упомянуты. 1-я - это строить схемы и писать процедуры для того, чтобы вытягивать сами значения наследуемых атрибутов из сущностей-родителей. 2-я - при создании сущностей-детей копировать все наследуемые значения в соответствующие атрибуты именно этих сущностей. Второй способ на мой взгляд лучше с точки зрения быстродействия выборки и обработки запросов на чтение. Первый способ сокращает издержки при записи и изменении значений атрибутов.

Вопрос возникает при перемещении по иерархии. Какие вообще перемещения считать допустимыми? Зависит ли признаки допустимости перемещений от типов сущностей. Есть ли у кого опыт анализа ситуаций в этой области? Или все предпочитают не заморачиваться данным вопросом, запретив перемещение типов в классификаторе (при наличии "наследования" атрибутов, в любом из предложенных видов)
Alexey Rovdo
Поле d_DocumentExtendedData.DataObjectID указывает на сущность, которая является значением атрибута. А ObjectTypeID ограничивает возможный выбор таких сущностей только одним типом (бизнес-логика). Чтобы было чуть понятнее приведу еще один модуль этой базы (простейшие сущности - параметры).
Ну где-то так я и думал (т.е. даже для атрибута "простого" типа вы отсылаете его в требуемую глобальную таблицу(ы) значений, кстати, в силу зависимости таблиц от типов, запрашивание величин атрибутов (или их интерфейсов - для сущностных) происходит динамически - ищем таблицу (поле) по типу объекта + ищем интерфейс по тем же признакам? Имена втавляем в строки запросов и т.п...?).
Хотя было сомнение.



2Dogen
Странно таки что нет других абстрактных схем. Головы то разные. Или у всех испорчены реляционным взглядом на вещи? (проскакивали тут намеки на нечто иное в принципе - какая то даже предикативная арифметика, казалось бы. Ихде они авторы?)