iv_an_ru
С моей точки зрения, есть страницы разных сортов --- со строками, LOBами, служебными данными, ну и просто пустые, размещённые в разном числе копий в разных местах --- в постоянной базе, во временной базе, или на других машинах кластера. Часть из них в каждый момент времени скопирована в память. Большая их часть занята под индексы разных типов --- деревья строк, деревья колонок, битмапы, сжатые/несжатые, уникальные/неуникальные и проч. Для удобства администрирования, эти индексы сгруппированы так, что один удовлетворяет некоторым специальным условиям и называется primary key, апп-девелопер ещё называет его "таблица". Есть куча портов, принимающих/отправляющих сообщения в соответствии с разнообразными протоколами, в том числе запросы на выполнение SQL и хранимых процедур. Эти запросы транслируются в те или иные манипуляции над индексами и выполняются.

А к какому классу продуктов относится то, что Вы делаете, на Ваш взгляд?

iv_an_ru
Классическая миддлварная реляционная СУБД.
Ну вот, а говорили, "Я то как раз не знаю":)
Может быть Вам удастся создать реляционную СУБД.

iv_an_ru
Вы спросили про "мой взгляд". По-моему --- RDBMS. А вот в Википедии юзеры написали про неё ORDBMS , и им, наверное, виднее :)
Да, сложная задачка:) Ну давайте попробуем ее решить.
1) Хоть Вы и не юзер, но наверное объяснить как в Вашей СУБД создать предельно упрощенную схему данных и как ее использовать:
Человек-получил-(1:М)->Образование
Человек {Фамилия (строка), Имя (строка), Дата рождения (дата)}
Образование {Дата поступления (дата), Дата окончания (дата), Квалификация (строка), Наименование учебного заведения (строка)}
2) После этого расскажите как реализован оптимизатор (если, конечно, это не промышленная тайна:)).
3) А после этого, как реализован снапшот, то есть возможность получать целостные результаты отчета при условии, что другие пользователи изменяют данные, читаемые для отчета.
Спасибо.

iv_an_ru
Давайте я сначала отвечу на первую часть вопроса.


Точнее, на первый вопрос. Давайте.

iv_an_ru
Можно создать три таблички --- "человек" (скажем, с целочисленным ID в роли PK), "образование" (тоже с ID PK) и связующую двухколоночную. Громоздко, зато в связующую можно потом накидать кучу доп.колонок с индексируемой ерундой, такой, как "номер диплома".


Нет, нельзя, так как схему данных я уже определил:) В ней два объекта и связь между ними.
Тем не менее, раз уж Вы это написали:
а) что за "целочисленный ID в роли PK"? это "поле" в "табличке" Человек? Так же, как и Фамилия - это "поле" в "табличке" человек? Но в объектной БД идентификатор не может быть среди характеристик объекта. Так что Вы правы (пока), что у Вас "реляционная" система...
б) значит в связующей двухколоночной (в перспективе -"многоколоночной") два FK, правильно? Это также не объектный подход - чужих идентификаторов и подавно не может быть среди характеристик:)
в) "накидать ерунды" можно, в данном случае и в "табличку" Образование. Если же Вы предлагаете связи (независимо от их мощности) представлять отдельными табличками, то это не получается. Вы же под "связями" понимаете механизм FK, правильно? Так вот, в Вашей "связующей" есть два FK, то есть, две связи, а ведь связи следует представлять отдельными табличками. И так до бесконечности:)
iv_an_ru
Можно создать только две --- "человек" и "образование", но в "человека" добавить поле --- список образований, и навесить на него "полнотекстовый индекс", где каждое образование будет представлено уникальным "словом", созданным из ID этого образования.


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

iv_an_ru
Давайте выберем ... тогда и про оптимизатор поговорим

Непонятно зачем нам это выбирать. У Вас оптимизатор еще и оптимизируется?:)
Ну давайте выберем. Большая-большая база на одной машине.
Итак, как работает оптимизатор?

iv_an_ru
... и выберем самый подходящий из многих способ устроить снапшот...

Они выбираются параметрически?:)
Ну хорошо, давайте выберем, условия определены в предыдущем сообщении.

iv_an_ru
... Наверное за этот синтаксический сахар нам и добавили буковку O к RDBMS :) А может, добавили за create type :)

То есть, я могу создать тип характеристики объекта "габариты"
A*B*C, где A, B, C - положительные числа.
И организовать в запросах, например, для подбора подходящей коробки для товара:
вмещает в себя 1000*500*200
а также и
вмещает в себя с вращением 1000*500*200 (если товар можно в этом прямоугольном параллепипеде кантовать:))
И все заработает, и в оптимизаторе будет оптимизироваться автоматически... Правильно я понимаю?

vadiminfoiv_an_ruА ещё если у нас людей очень много, а образованных среди них очень мало, то можно выпендриться и сделать табличку "образованный человек" наследованием от "просто человек". Наверное за этот синтаксический сахар нам и добавили буковку O к RDBMS :) А может, добавили за create type :)
Ну Бредятина в эту табличку не попадает по любасу: образованость не его сильная сторона, он вседа славился необычайной наивностью в области технологий БД.
Потому лабайте табличку "необразованный человек". Там ЧАЛ первым номером и пойдет. И за эту семантическую соль земли, добавьте букву О к налабаной ЧАЛом в Балабанове оболочке Каши ИнформХ. А ОРСУБД моно буит оставить тем парням, что разбираются в данном предмете более или менее. И все тада останутся при своем.
Дельное, кстати, предложение для совершенствования Вашей СУБД от более или менее парня. Рекомендую прислушаться:)

iv_an_ru В данном случае "метаданные" ограничены списками и типами колонок, ну и индексами. Даже для контроля целостности связей от person до education потребуются триггеры, формально FK отсутствует.
В моем примере нет никаких е_sdate или p_fname. Где метаданные-то? Насколько я понимаю, в приложениях? Ну это совсем не годится в 21 веке:)
Что касается связи между "нашими" двумя объектами, это что-то запредельное. Практически Вы не смогли объявить связь при описании схемы. Ясно, что триггеры могут использоваться ("до" и "после" к созданию экземпляра связи и удалению экземпляра связи), но где сама-то связь (триггеры же вовсе не обязательны)?

_модБредятинаЯ даже более простой пример могу предложить - в концептуальной модели есть одна сущность Реальный мир. И т.п.
Одна не интересно, связей не будет. А что касается накладных, то их специально раскладывают на таблицы, чтобы можно было с ними работать формальными методами. Т.е. конц. модель=логич. модель в общем случае не катит.
Не просто катит, а замечательно катит:) И я даже показал как. Раскладывают не на таблицы, а на объекты. Вы слишком буквально связываете концептуальную модель БД с ручной информационной системой, сложившейся в XIV-XV веках:)

Озверин_модБредятинаЯ даже более простой пример могу предложить - в концептуальной модели есть одна сущность Реальный мир. И т.п.
Одна не интересно, связей не будет. А что касается накладных, то их специально раскладывают на таблицы, чтобы можно было с ними работать формальными методами. Т.е. конц. модель=логич. модель в общем случае не катит.

в каком смысле не будет связей?
бд имеющая одну абстрактную таблицу - не может являться реляционной?Оо
Не стоило применять прилагательное "абстрактую"...
Почему же не может. Может. Но речь же идет о "связях". А в "реляционной" БД связи реализуются с помощью FK->PK. Теоретически, можно в одной таблице сделать множество FK->PK:)
Но, скорее всего, эта таблица не будет в 1НФ, и тогда ее врядли можно назвать "реляционной".

iv_an_ruБредятинаЧто касается связи между "нашими" двумя объектами, это что-то запредельное.Ну вы сами захотели посмотреть на извратный вариант. Вот, пожалуйста.

Лично я или три таблички завёл бы, или ноль (или "гибридный" вариант с часто встречающимися данными в табличке + RDF View и редкими/нерегулярными в "настоящем" RDF).

Вы несколько преувеличиваете про "извратный вариант":) Одному Вам известно, почему для связи 1:М Вы просто не сделали FK в "табличке" Образование.
Остается только подозревать, что у Вас и в первом варианте нет FK в промежуточной "табличке":)
Итак, пока складывается впечатление (если с FK все в порядке), что Вы разрабатываете программу, выполняющую часть функций СУБД, в которой частично (как и во всех промышленных СУБД) поддерживается реляционная модель данных.

ОзверинОзверинБредятина
Как я уже упомянул в объект не корректно добавлять идентификаторы (теперь множество идентификаторов), как одну из характеристик объекта, если бы у Вас была объектная система. Но теперь получается, что у Вас, все-таки, и не "реляционная" система, ведь значение этой характеристики не атомарное: )

про атомарность обьекта не до конца понял, можно разжевать?

Ув. Бредятина, могли разжевать этот пост? Я в самом деле не до конца понял, что вы тут имели ввиду.

А у Вас сложилось впечатление, что с приведенным автором типом все ясно, и его значения можно считать атомарными?:)
Что значит "разжевать"? Вот пример разжевывания для студентов:
http://www.cyberguru.ru/database/database-theory/relational-database-normalization-page5.html
Но Вы-то точно не студент:)
Значением атрибута может быть и отношение, но в "нашем случае" с типом пока ничего не ясно.