Встретил фразу http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1161120&msg=17889208]"...парадигма OOP плохо ложит ь ся на реляционные отношения..." . Прям аж обидно стало, я на эту тему здесь распинался лет десять назад, уже по европам с этим потихоньку стал ездить, а тут бац!... снова "плохо ложит ь ся".

Вот для ознакомления стендовый доклад . В формальной основе, кстати, ничего кроме старой РМД.

КМК проблема исключительно в зашоренности, которая проявляется в том, что объект пытаются так или иначе воткнуть внутрь одной таблицы (как строку, или как поле строки). А если выйти из этого ограничения, то всё ложиться со свистом и с кучей новых интересных фич. То есть, что бы правильно положить, надо использовать "реляционные отношения" во множественном числе (а если лОжить на одно "реляционное отношение", в единственном числе, то и правда - не положиться).

Что самое забавное - по большому счету этот принцип "лОжения ООП на отношения" давным-давно используются кучей систем (тех же бизнес- систем, тем же 1С), которые собирают свои объекты из разных строк разных таблиц. Однако они таскают данные из БД, но ведь никто не мешает пойти в другую сторону - оставить данные в СУБД, а заставить её обрабатывать команды, работающие с такими объектами. Мне удивительно, это же очевидно, почему этого никто не видит?

Yo.!,

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

Настаивать не стал.

Это я к чему? Сама Ваш фраза показывает что Вы о чем-то своем со мной спорите, а я совсем про другое . Но я не настаиваю.

:)

Yo.!,

Расшифрую
1) Вы в свой фразе упомянули какие то технологии. Я говорю про логику.
2) В моем исходном посте была фраза "Однако они таскают данные из БД, но ведь никто не мешает пойти в другую сторону - оставить данные в СУБД, а заставить её обрабатывать команды, работающие с такими объектами". То, что выделено красным - это, в том числе, про hibernate и про километровые простыни, которые надо парсить. А я про "пойти в другую сторону".

ViPRos,

о какой прокладке идет речь? я не понимаю.

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

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

Поэтому я не могу понять, о чем спрашивает ViPRos.

Кроме того, там внизу строка, "эффективная реализация новых возможностей требует изменения в ядрах СУБД", поэтому откуда взялась "прокладка", мне совсем не понятно.

ViPRos

Вы как то мыслите.... "Не положено, и всё тут!". А почему нельзя?

ViPRosнечего "таблицам" валяться рядом с объектами
Ну вот есть схема какого то бизнеса. Там есть какие то документы(объекты) и журналы(таблицы), и собраны они в одной схеме. Почему нельзя таблицам быть в одной схеме с объектами?
ViPRosтаблички - логический контейнер для хранения (нужен для РМД движка)
Ну и хорошо. А объекты - тоже этакие контейнерчики (хотя как они хранят данные, зависит от их реализации). Они в одной схеме с таблицами. Почему нельзя?

ViPRosСКЛ внутренний язык (язык движка)
должен быть другой язык, который надо автоматом транслировать на СКЛ (пока, в дальнейшем напрямую) Почему? Зачем? Ну вот правда, ну зачем это? ну если SQL вместе с некоторыми доп. командами достаточен для описания бизнеса на уровне 1С и даже более того - зачем еще один язык?

Yo.!,

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

Вас в миру, случайно, не Олегом звать?

Впрочем очень многие страдают от того же. Мне приходится часто такие "экспертные мнения" слышать, диву даешься.

Yo.!,

Расшифрую, по некоторым отличиям.
1) ООСУБД предназначены для хранения объектов языков программирования, типа С++. То есть, всяко подразумевается существование программы, из которой объекты с легкостью можно было бы сохранить в БД. Делалось это программистами для программистов, хотя подразумевались благие цели всеобщего счастья. Но на практике вышло, что помимо тупого хранение данных, существует куча других требований, которым ООСУБД никак не соответствовали. Поэтому они успешно окочурились.
2) ООСУБД отверагли РМД и предлагали свое то, что они называли "моделью". Были попытки даже стандартизировать все это безобразие в виде стандартов ОDMG. Кстати, портал ODMG.ORG до сих пор успешно работает, правда он провел ре-брендинг, теперь "O" означает "оperational"

ViPRos,

Снова ответ в стиле "не положено" :)

А если они нужны эти таблицы, именно как таблицы? Ну... журнал там какой вести? Зачем что то лишнее выдумывать, если оно уже есть?

ЗимарглОбъектное хранение и РМД - ортогональные сущности. Как ни скрещивай - будет жопа.

Причем здесь "Объектное хранение "? Я ж не про хранения объектов в БД, а про их персистентное активное существование. Объекты в БД и нигде никогда больше. Это уже не БД в классическом смысле (хранения данных), а скорее активная модель. Внутрь идут команды, наружу данные о состоянии модели.

ЗимарглНа базе иерархической БД всегда можно построить надстройку, которая будет реализовывать РМД без необратимых потерь в производительности (линейная зависимость), обратная операция - существенно затратнее. Это верно для надстроек, но я не про надстройку.

Зимаргл,

Ну вот смотри.

Есть, например, две таблицы (извиняюсь за условный язык) и UDF


Классический случай нормализации документа, плюс функция, которая учитывает отдельные документы. Но в БД все валяется по отдельности и пользователь должен в голове держать, что эти три фигни по факту относятся к одной бизнес -сущности, к одному документу.

Вместо этого можно использовать что то типа


По факту я сообщаю СУБД инфу, достаточную для того, что бы СУБД сама унтутри создала эти две таблицы и хранимку. Но, при этом, я сообщаю ей, что все это относится к одной сущности, поэтому она может там унутри поступать хитрее, например, для того, что бы не джойнить записи из двух таблиц (как это следует из теории), а как то их в ОЗУ ссылками один раз и навсегда связывать при загрузке, или вообще хранить на диске объекты целиком, а при чтении в память их заоодно по условным табличным буферам раскидывать и тп. В общем всё это скрыто, всё это соответствует теории (по которой типа выполняется JOIN). Самое главное, пользователь работает с такими объектами, имея такую сложную сущность в схеме своей БД, поэтому для него схема БД выглядит гетерогенной, в смысле такие объекты и старые таблицы рядом.

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

ЗимарглU-gene,

Что то твой мох длиннее моего (

Ты про то, что засунуть трехзвенку внутрь БД ?

Блин, вот я про это и говорю, вещь же простейшая, а не доходит :) НУ при чем здесь "засунуть трехзвенку?"

Я написал. "Однако они таскают данные из БД, но ведь никто не мешает пойти в другую сторону - оставить данные в СУБД, а заставить её обрабатывать команды, работающие с такими объектами." Нет объектов внутри, есть преобразование команд.

Например в ОЗУ в момент исполнения С++ программы нет объектов, а есть линейный набор байтов. А когда мы писали программу на С++, то мыслили объектами, потом транслятором прошлись и он наши мысли в свои преобразовал. Так и здесь. Выполняется трансляция. Объектов внутри точно нет нив каком виде. С формальной точки зрения есть таблицы. А реально могут быть вообще любые структуры данных, буфера и указатели, важно лишь, что бы было эффективно и внешне формализму соответствовало.

ViPRosЗимаргл,

нет никакой проблемы с производительностью
есть проблема БОЛЬШАЯ - СУБД не знает ЧТО хранит, если бы знала все было бы нормализовано до последнего битика
есть проблема ЬОЛЬШАЯ - СУБД не знает ЗАЧЕМ хранить, если б знала, то запросы (для зачем) были бы сгенерированы и оптимизированы загодя пока какой нить ишак не спросит
проблема - семантика

вот, и я про это.