Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
 парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Встретил фразу "...парадигма OOP плохо ложиться на реляционные отношения...". Прям аж обидно стало, я на эту тему здесь распинался лет десять назад, уже по европам с этим потихоньку стал ездить, а тут бац!... снова "плохо ложиться".

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

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

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

------------------------------
!Напрасный труд хуже пьянства!
------------------------------
31 июл 15, 00:05    [17957899]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
Yo.!
Guest
U-gene,

все верно, ложится плохо. у меня оракл с лучшем на шарике оптимизатором дохнет от запросов хибернейта, приходиться переписывать запросы на SQL потому, что рсубд реально больше тратят время на парсинг простыней запросов от ОРМ, чем не посредственно на выполнение.
31 июл 15, 00:24    [17957939]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Yo.!,

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

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

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

:)
31 июл 15, 00:33    [17957956]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Yo.!,

Расшифрую
1) Вы в свой фразе упомянули какие то технологии. Я говорю про логику.
2) В моем исходном посте была фраза "Однако они таскают данные из БД, но ведь никто не мешает пойти в другую сторону - оставить данные в СУБД, а заставить её обрабатывать команды, работающие с такими объектами". То, что выделено красным - это, в том числе, про hibernate и про километровые простыни, которые надо парсить. А я про "пойти в другую сторону".
31 июл 15, 00:44    [17957970]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
ViPRos
Member

Откуда:
Сообщений: 9965
U-gene,

ну в другую сторону надо пойти не путем прокладок над существующей СУБД, а путем введение нормального понятия СХЕМЫ (не пользователя, не просто куча фигни всякой, а схемы - как описание схемы объекта)
тогда и СКЛ стал бы проще и не надо было бы Оптимизировать :)
а прокладок много, включая и твой (кто то осмысленно делал, а кого то кривая вывезла (как 1с))
31 июл 15, 01:05    [17957997]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
ViPRos,

о какой прокладке идет речь? я не понимаю.
31 июл 15, 01:07    [17958002]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

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

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

Поэтому я не могу понять, о чем спрашивает ViPRos.
31 июл 15, 01:16    [17958011]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Кроме того, там внизу строка, "эффективная реализация новых возможностей требует изменения в ядрах СУБД", поэтому откуда взялась "прокладка", мне совсем не понятно.
31 июл 15, 01:20    [17958019]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
ViPRos
Member

Откуда:
Сообщений: 9965
U-gene,

ну я не читал эти ссылки
нечего "таблицам" валяться рядом с объектами
таблички - логический контейнер для хранения (нужен для РМД движка)
СКЛ внутренний язык (язык движка)
должен быть другой язык, который надо автоматом транслировать на СКЛ (пока, в дальнейшем напрямую)
31 июл 15, 01:34    [17958033]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
Yo.!
Guest
U-gene
2) В моем исходном посте была фраза "Однако они таскают данные из БД, но ведь никто не мешает пойти в другую сторону - оставить данные в СУБД, а заставить её обрабатывать команды, работающие с такими объектами". То, что выделено красным - это, в том числе, про hibernate и про километровые простыни, которые надо парсить. А я про "пойти в другую сторону".

а простите, не допер, что на отдаленных хуторах еще не слышали о моде на ООП субд в 90х годах прошлого века.
реально тема уже лет 10 как никому не интересна, т.к. практике достаточно быстро все поняли, что с реляционностью у ООП ничерта общего нет, а вот с иерархическими субд они просто созданы друг для друга. неужели в вашем послеке совсем не слышали о моде на оосубд в 90х ?
31 июл 15, 01:35    [17958034]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
ViPRos
Member

Откуда:
Сообщений: 9965
Yo.!,

иерархические субд в этом отношение еще хуже чем рмд
данные НЕ ДОЛЖНЫ быть связаны
а вот СХЕМА - ДА
потому сетевая схема (мультиграф) на фасаде, а РМД с СКЛ нижний уровень
31 июл 15, 01:37    [17958037]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
ViPRos

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

ViPRos
нечего "таблицам" валяться рядом с объектами

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

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

ViPRos
СКЛ внутренний язык (язык движка)
должен быть другой язык, который надо автоматом транслировать на СКЛ (пока, в дальнейшем напрямую)
Почему? Зачем? Ну вот правда, ну зачем это? ну если SQL вместе с некоторыми доп. командами достаточен для описания бизнеса на уровне 1С и даже более того - зачем еще один язык?
31 июл 15, 01:52    [17958042]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Yo.!,

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

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

Впрочем очень многие страдают от того же. Мне приходится часто такие "экспертные мнения" слышать, диву даешься.
31 июл 15, 02:02    [17958049]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Yo.!,

Расшифрую, по некоторым отличиям.
1) ООСУБД предназначены для хранения объектов языков программирования, типа С++. То есть, всяко подразумевается существование программы, из которой объекты с легкостью можно было бы сохранить в БД. Делалось это программистами для программистов, хотя подразумевались благие цели всеобщего счастья. Но на практике вышло, что помимо тупого хранение данных, существует куча других требований, которым ООСУБД никак не соответствовали. Поэтому они успешно окочурились.
2) ООСУБД отверагли РМД и предлагали свое то, что они называли "моделью". Были попытки даже стандартизировать все это безобразие в виде стандартов ОDMG. Кстати, портал ODMG.ORG до сих пор успешно работает, правда он провел ре-брендинг, теперь "O" означает "оperational"
31 июл 15, 02:19    [17958057]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
ViPRos
Member

Откуда:
Сообщений: 9965
U-gene,

СКЛ в типизированном мире не нужен
таблицы и схемы - это разные уровни
схемы описывают логические связи вершин графа
таблички - хранят и эту инфу и инфу в самих ребрах и вершинах
к таблицам прямого доступа не должно быть
31 июл 15, 02:22    [17958058]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
ViPRos,

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

А если они нужны эти таблицы, именно как таблицы? Ну... журнал там какой вести? Зачем что то лишнее выдумывать, если оно уже есть?
31 июл 15, 02:27    [17958059]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
Зимаргл
Guest
Объектное хранение и РМД - ортогональные сущности. Как ни скрещивай - будет жопа.

В большинстве случаев конечно просто добавить в РМД поле типа произвольный массив и 90% проблем с неудобством реализации будут решены. Потому в классике SQL появились XML поля и прочий JSON.

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

Массив свойств в массиве объектов это в случае РМД квадратичная, или же в лучшем случае, логарифмическая зависимость поиска.
При удобном проектировании объектов - корневая. Это на первый косой взгляд, потому предлагаю посчитать.
31 июл 15, 02:30    [17958061]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
ViPRos
Member

Откуда:
Сообщений: 9965
U-gene
ViPRos,

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

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

журнал ведут СЕЙЧАС - потому что проектировщики тупые, а инструменты проектирования очень слабы
как только человек (он всегда будет тупой) проектирует:) журнал, то система автоматически должна вычленить понятия, связать с имеющимися, строить схему, нормализовать, прибиндить имеющиеся поведение и вернуть обратно приложение для этого говнюка

т.е. спрашиваю (проектирую) как могу, а получаю квалифицированный ответ в виде формального описания предметной области
31 июл 15, 02:34    [17958062]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
ViPRos
Member

Откуда:
Сообщений: 9965
Зимаргл,

нет никакой проблемы с производительностью
есть проблема БОЛЬШАЯ - СУБД не знает ЧТО хранит, если бы знала все было бы нормализовано до последнего битика
есть проблема ЬОЛЬШАЯ - СУБД не знает ЗАЧЕМ хранить, если б знала, то запросы (для зачем) были бы сгенерированы и оптимизированы загодя пока какой нить ишак не спросит
проблема - семантика
31 июл 15, 02:37    [17958063]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
Зимаргл
Guest
ViPRos
Зимаргл,

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

РМД это и есть нормализация до последнего битика. Но когда твой объект идеально распадается в нормализации на 20 таблиц, то все запросы, что вдоль что поперек имеют абсолютно посчитанную обоснованную математически затратность. Но она велика.

Если ты объекты раскладываешь так, как как тебе нужно для запросов, то затратность этих запросов низкая всегда. Зато для неудобных в этой схеме хранения - будет линейный поиск.

А так ты прав - СУБД не знает что тебе нужно, а ты знаешь. Но в РМД твое знание почти ничего не даст.
31 июл 15, 02:47    [17958068]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

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


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

Зимаргл
На базе иерархической БД всегда можно построить надстройку, которая будет реализовывать РМД без необратимых потерь в производительности (линейная зависимость), обратная операция - существенно затратнее.
Это верно для надстроек, но я не про надстройку.
31 июл 15, 02:53    [17958070]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
Зимаргл
Guest
U-gene,

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

Ты про то, что засунуть трехзвенку внутрь БД ?
31 июл 15, 02:58    [17958072]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Зимаргл,

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

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

CREATE TABLE SalesHeader{			
DocN STRING;
Buyer STRING;
...
PostIt(inDate DATETIME);
}KEY uniqDocN (DocN)

CREATE TABLE SalesHeader
{ DocN STRING;
Art SRTING; //foreign key
Qty INTEGER;
}KEY uArt (DocN,Art);

CREATE FUNCTION DoPost(DocN STRING)....

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

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

CREATE CLASS Sales{			
DocN STRING; //Scalar attr.
Buyer STRING;// Scalar attr.
...
Items SET OF //Table attr.
{ Art GOODS; //Reference
Qty INTEGER;
}KEY uArt (Art); //Table field key
PostIt(inDate DATETIME); //Method
}KEY uniqDocN (DocN)//Class key

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

Надо учитывать, что такая схема класса требует в дальнейшем полной реализации, пи этом любой атрибут может храниться или вычисляться.
31 июл 15, 03:18    [17958076]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Зимаргл
U-gene,

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

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


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

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

Например в ОЗУ в момент исполнения С++ программы нет объектов, а есть линейный набор байтов. А когда мы писали программу на С++, то мыслили объектами, потом транслятором прошлись и он наши мысли в свои преобразовал. Так и здесь. Выполняется трансляция. Объектов внутри точно нет нив каком виде. С формальной точки зрения есть таблицы. А реально могут быть вообще любые структуры данных, буфера и указатели, важно лишь, что бы было эффективно и внешне формализму соответствовало.
31 июл 15, 03:26    [17958077]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
ViPRos
Зимаргл,

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


вот, и я про это.
31 июл 15, 03:31    [17958078]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить