ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / парадигма OOP плохо ложиться на реляционные отношения...?
25 сообщений из 108, страница 1 из 5
  1  все
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019952
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Встретил фразу http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1161120&msg=17889208]"...парадигма OOP плохо ложит ь ся на реляционные отношения..." . Прям аж обидно стало, я на эту тему здесь распинался лет десять назад, уже по европам с этим потихоньку стал ездить, а тут бац!... снова "плохо ложит ь ся".

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

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

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

Код: plaintext
1.
2.
------------------------------
!Напрасный труд хуже пьянства!
------------------------------
...
Рейтинг: 0 / 0
31.07.2015, 00:05
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019956
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
U-gene,

все верно, ложится плохо. у меня оракл с лучшем на шарике оптимизатором дохнет от запросов хибернейта, приходиться переписывать запросы на SQL потому, что рсубд реально больше тратят время на парсинг простыней запросов от ОРМ, чем не посредственно на выполнение.
...
Рейтинг: 0 / 0
31.07.2015, 00:24
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019958
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Yo.!,

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

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

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

:)
...
Рейтинг: 0 / 0
31.07.2015, 00:33
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019961
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Yo.!,

Расшифрую
1) Вы в свой фразе упомянули какие то технологии. Я говорю про логику.
2) В моем исходном посте была фраза "Однако они таскают данные из БД, но ведь никто не мешает пойти в другую сторону - оставить данные в СУБД, а заставить её обрабатывать команды, работающие с такими объектами". То, что выделено красным - это, в том числе, про hibernate и про километровые простыни, которые надо парсить. А я про "пойти в другую сторону".
...
Рейтинг: 0 / 0
31.07.2015, 00:44
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019966
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
U-gene,

ну в другую сторону надо пойти не путем прокладок над существующей СУБД, а путем введение нормального понятия СХЕМЫ (не пользователя, не просто куча фигни всякой, а схемы - как описание схемы объекта)
тогда и СКЛ стал бы проще и не надо было бы Оптимизировать :)
а прокладок много, включая и твой (кто то осмысленно делал, а кого то кривая вывезла (как 1с))
...
Рейтинг: 0 / 0
31.07.2015, 01:05
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019968
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ViPRos,

о какой прокладке идет речь? я не понимаю.
...
Рейтинг: 0 / 0
31.07.2015, 01:07
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019970
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Кстати, два ответа хорошо демонстрируют, что основная трудность в объяснении - добиться того, что бы головы слушающего стала чистой. Ну, или что бы он хотя бы внимательно ознакомился с тем, что ему предлагается.

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

Поэтому я не могу понять, о чем спрашивает ViPRos.
...
Рейтинг: 0 / 0
31.07.2015, 01:16
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019973
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Кроме того, там внизу строка, "эффективная реализация новых возможностей требует изменения в ядрах СУБД", поэтому откуда взялась "прокладка", мне совсем не понятно.
...
Рейтинг: 0 / 0
31.07.2015, 01:20
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019976
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
U-gene,

ну я не читал эти ссылки
нечего "таблицам" валяться рядом с объектами
таблички - логический контейнер для хранения (нужен для РМД движка)
СКЛ внутренний язык (язык движка)
должен быть другой язык, который надо автоматом транслировать на СКЛ (пока, в дальнейшем напрямую)
...
Рейтинг: 0 / 0
31.07.2015, 01:34
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019977
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
U-gene2) В моем исходном посте была фраза "Однако они таскают данные из БД, но ведь никто не мешает пойти в другую сторону - оставить данные в СУБД, а заставить её обрабатывать команды, работающие с такими объектами". То, что выделено красным - это, в том числе, про hibernate и про километровые простыни, которые надо парсить. А я про "пойти в другую сторону".
а простите, не допер, что на отдаленных хуторах еще не слышали о моде на ООП субд в 90х годах прошлого века.
реально тема уже лет 10 как никому не интересна, т.к. практике достаточно быстро все поняли, что с реляционностью у ООП ничерта общего нет, а вот с иерархическими субд они просто созданы друг для друга. неужели в вашем послеке совсем не слышали о моде на оосубд в 90х ?
...
Рейтинг: 0 / 0
31.07.2015, 01:35
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019978
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
Yo.!,

иерархические субд в этом отношение еще хуже чем рмд
данные НЕ ДОЛЖНЫ быть связаны
а вот СХЕМА - ДА
потому сетевая схема (мультиграф) на фасаде, а РМД с СКЛ нижний уровень
...
Рейтинг: 0 / 0
31.07.2015, 01:37
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019979
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ViPRos

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

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

ViPRosСКЛ внутренний язык (язык движка)
должен быть другой язык, который надо автоматом транслировать на СКЛ (пока, в дальнейшем напрямую) Почему? Зачем? Ну вот правда, ну зачем это? ну если SQL вместе с некоторыми доп. командами достаточен для описания бизнеса на уровне 1С и даже более того - зачем еще один язык?
...
Рейтинг: 0 / 0
31.07.2015, 01:52
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019980
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Yo.!,

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

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

Впрочем очень многие страдают от того же. Мне приходится часто такие "экспертные мнения" слышать, диву даешься.
...
Рейтинг: 0 / 0
31.07.2015, 02:02
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019982
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Yo.!,

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

СКЛ в типизированном мире не нужен
таблицы и схемы - это разные уровни
схемы описывают логические связи вершин графа
таблички - хранят и эту инфу и инфу в самих ребрах и вершинах
к таблицам прямого доступа не должно быть
...
Рейтинг: 0 / 0
31.07.2015, 02:22
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019984
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ViPRos,

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

А если они нужны эти таблицы, именно как таблицы? Ну... журнал там какой вести? Зачем что то лишнее выдумывать, если оно уже есть?
...
Рейтинг: 0 / 0
31.07.2015, 02:27
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019985
Зимаргл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зимаргл
Гость
Объектное хранение и РМД - ортогональные сущности. Как ни скрещивай - будет жопа.

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

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

Массив свойств в массиве объектов это в случае РМД квадратичная, или же в лучшем случае, логарифмическая зависимость поиска.
При удобном проектировании объектов - корневая. Это на первый косой взгляд, потому предлагаю посчитать.
...
Рейтинг: 0 / 0
31.07.2015, 02:30
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019986
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
U-geneViPRos,

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

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

т.е. спрашиваю (проектирую) как могу, а получаю квалифицированный ответ в виде формального описания предметной области
...
Рейтинг: 0 / 0
31.07.2015, 02:34
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019987
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
Зимаргл,

нет никакой проблемы с производительностью
есть проблема БОЛЬШАЯ - СУБД не знает ЧТО хранит, если бы знала все было бы нормализовано до последнего битика
есть проблема ЬОЛЬШАЯ - СУБД не знает ЗАЧЕМ хранить, если б знала, то запросы (для зачем) были бы сгенерированы и оптимизированы загодя пока какой нить ишак не спросит
проблема - семантика
...
Рейтинг: 0 / 0
31.07.2015, 02:37
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019988
Зимаргл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зимаргл
Гость
ViPRosЗимаргл,

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

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

А так ты прав - СУБД не знает что тебе нужно, а ты знаешь. Но в РМД твое знание почти ничего не даст.
...
Рейтинг: 0 / 0
31.07.2015, 02:47
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019989
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ЗимарглОбъектное хранение и РМД - ортогональные сущности. Как ни скрещивай - будет жопа.

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

ЗимарглНа базе иерархической БД всегда можно построить надстройку, которая будет реализовывать РМД без необратимых потерь в производительности (линейная зависимость), обратная операция - существенно затратнее. Это верно для надстроек, но я не про надстройку.
...
Рейтинг: 0 / 0
31.07.2015, 02:53
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019990
Зимаргл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зимаргл
Гость
U-gene,

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

Ты про то, что засунуть трехзвенку внутрь БД ?
...
Рейтинг: 0 / 0
31.07.2015, 02:58
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019991
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Зимаргл,

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

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
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)....

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

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
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). Самое главное, пользователь работает с такими объектами, имея такую сложную сущность в схеме своей БД, поэтому для него схема БД выглядит гетерогенной, в смысле такие объекты и старые таблицы рядом.

Надо учитывать, что такая схема класса требует в дальнейшем полной реализации, пи этом любой атрибут может храниться или вычисляться.
...
Рейтинг: 0 / 0
31.07.2015, 03:18
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019992
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ЗимарглU-gene,

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

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

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

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

Например в ОЗУ в момент исполнения С++ программы нет объектов, а есть линейный набор байтов. А когда мы писали программу на С++, то мыслили объектами, потом транслятором прошлись и он наши мысли в свои преобразовал. Так и здесь. Выполняется трансляция. Объектов внутри точно нет нив каком виде. С формальной точки зрения есть таблицы. А реально могут быть вообще любые структуры данных, буфера и указатели, важно лишь, что бы было эффективно и внешне формализму соответствовало.
...
Рейтинг: 0 / 0
31.07.2015, 03:26
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019993
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ViPRosЗимаргл,

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

вот, и я про это.
...
Рейтинг: 0 / 0
31.07.2015, 03:31
| Ответить | Цитировать | Написать  
25 сообщений из 108, страница 1 из 5
  1  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / парадигма OOP плохо ложиться на реляционные отношения...?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/search_topic.php?author=Vladimir_Vertica&author_mode=last_posts&do_search=1]:
 0ms
get settings:
 10ms
get forum list:
 14ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 41ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 59ms
get tp. blocked users:
 1ms
others: 438ms
total:  604ms
созд. / загр.: 604ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]