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

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

Если возможно - хотелось бы кратко видеть следующее - структура хранилища на уровне идей + структура (ядро) на уровне реализации БД - CREATE TABLE-ы (упрощенно). Реализация интерфейса юзера мне в этом контексте не интересна (хотелось бы оставить ее за скобками, или как дополнительное обоснование к выбору структуры).

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

Alexey Rovdo
2. Вы хотите рассмотреть возможные варианты построения только реляционных структур или как один из способов решения проблемы допускаете использование объектных технологий (объектные СУБД, инструментарий для объектно-реляционного отображения, объектные расширения классических СУБД) ?
Меня интересуют только варианты реляционных структур. На самом деле вопрос - в каких абстракциях, допускающих реализацию в реляционных структурах, наиболее полно описываются такие хранилища (возможно, и даже наиболее вероятно - с учетом особенностей неких областей приложения - т.е. с некими ограничениями на тип хранимых сущностей и связей). Я хочу концентрировать те конструктивные мысли (подходы), которые разбросаны во множестве в разных топиках.

Спасибо.

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

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

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

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

mv
Заведи справочник бизнес - типов:

Название
Базовый тип

по построению этого справочника видимо больших расхождений тоже нет?
Правда нужен ID бизнес_типа? (названия могут быть весьма длинными?).

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


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

mv
Документы (n)- Значения - (1) Бизнес - типы

Для каждого значения храни его представление в виде строки или заведи что-нибудь в виде записи с вариантами.

Документы - это то, что мы называли ранее сущностями? (только теперь это более узкое понятие?). Как в вашей модели организовано (предполагается быть организованным) хранение ЭТИХ САМЫХ "документов"? Считаете ли вы, что это описатели "типов" сущностей? Как они (описатели) организованы?

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

Или значения - это значения самих СВОЙСТВ "документа" - т.е. таблица "св-ва", связанная с таблицей "Документ", и осуществляющая привязку к документу как типа св-ва, так и его значения?

mv
Чтобы разгрузить систему, для справочника Значения введи Null - значение и, если значение равно null, просто не создавай эту запись.
Что такое справочник "Значения"? Это еще одна таблица? И каждое значение (float8) я должен хранить и в нем??? . Или "просто" имеется в виду в _интерфейсе_ заполнения значений свойств, при выборе значений _ссылочных_ типов добавлять к набору еще и значение Null? И при вводе пользователем Null в поле соответствующего базового типа удалять заполняемую/изменяемую запись???

Хотелось бы понять, из какого набора абстракций ("Документ"/"Свойство"/"Значение"/"Тип"/"Базовый тип") состоит ваша модель. И где (в какой из абстракций) в ней описана/хранится структура (модифицируемая!) "документов", а где - сами(?) "документы" (или они называются иначе?). Или не предполагается отдельного хранения "структур"?



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

skorohod /topic/134831&pg=14

Спасибо, смотрел.
skorohod
Наверно эта ветвь форума не совсем соответствует Вашему вопросу.
Вот если-бы ввести отдельную тему в ветви "Сравнение СУБД" (напр. "Сравнение реализаций ОР СУБД") - можно было-бы вести обсуждение Вашего вопроса там.

Меня интересуют не сравнения СУБД, а "типовые" решения хранилищ "плохоструктурированных данных" (вернее данных, описание которых вводятся/модифицируются вместе с вводом/модификацией самих данных). Т.е. именно "_конструктивные_особенности_" схем данных, позволяющих таковое размещение без переконструирования структуры.
- "Объектные" надстройки, выполняющие "криэйт таблы" на каждую вносимую сущность меня мало интересуют, ибо проблема не в том, что я хочу размещать модное слово "объект", а в том, что то, что я хочу размещать, будеть подвижно, и должно быть описано в таких терминах, которые будут достаточны для покрытия всего, что только сможет быть размещено, причем "покрытие" должно осуществляться как со стороны помещения так и со стороны интерпретации данных (т.е., в известном смысле - интерфейса - т.к., сдается мне, если набор абстракций, воплощенных в некую схему БД, позволяет интерпретировать сохраненную в ней информацию {на основе сохраненной в ней-же информации "об интерпретации"}, то стало быть и позволяет [понятную юзеру] визуализацию этой интерпретации - сиречь интермордс).


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

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

А далее, сдается таки мне, существует уже (в природе) некое количество реализаций таковых построений, т.е. такого "анализа" нашей "предметной области". И у этих реализаций есть и свои особенности, и свои плюсы и минусы. И свои принципы, порождающие и то и другое. И именно как у архитектур конкретных, "обычных реляционных БД" (а отнюдь не их {ОООООРРРРРРР}СУБД). Вот и хотелось все это и оборзеть, сведя в какую-то систему.


Вот собственно и все соображения, по каковым этот вопрос задан именно тут.
Т.е. (резюме) вопрос-то в сущности в том, _как_ спроектировать реляционную БД для хранения "знаний": т.е. упирается в описание предметной модели "знаний" (возможные варианты построения моделей, их плюсы и минусы).


________________________
ЗЫ: skorohod
А так, есть только тема
http://www.sql.ru/forum/actualthread.aspx?tid=9021
которая тянется уже третий год, и охватывает и объектно-ориентированные и реляционные и объектно-реляционные СУБД, и большая часть постов в ней типа "сам дурак", хотя есть и полезные...
в этих темах есть все: - и "сам дурак", и "надстройки-построители конформных баз" (обзовем их так) и реализации в упомянутом выше смысле (в смысле отображения анализа предметной области на "стандартную" структуру БД, но с выделенными нами панацейными сущностями и связями). Вот и хотел эти последние выделить в отдельном месте. И именно как структур даных.