ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / парадигма OOP плохо ложиться на реляционные отношения...?
108 сообщений из 108, показаны все 5 страниц
  все  
парадигма 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
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019994
Зимаргл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зимаргл
Гость
В Cache так и сделано поверх иерархического хранения.

А в целом такая система очень плохо масштабируется:
-или берем большой большой мейнфрейм и все ок
-или можно засунуть инмемори с технологией типа CoW

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

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

ЗимарглА в целом такая система очень плохо масштабируется:
-или берем большой большой мейнфрейм и все ок
-или можно засунуть инмемори с технологией типа CoW
Насчет "очень плохо масштабируется" я не понял, с чего такой вывод. Реляционные СУБД вообще не очень масштабируются, но я же не обещаю решения всех вопросов.

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

Короче, очевидный велосипед.

Ой, нам бы ваши масштабы бггг.
Я то думаю о себе в молодости.Мне такая бы штука очень пригодилась бы для моих решений для всяких бизнесов. Да и сейчас таких как я - тысячи. Кто то возится с 1С. По нынешним ценам на память, ОЗУ недорого сервера вместит БД средне-статистического предприятия несколько раз, инмемори он или просто так. Там масштабирование и распределение не очень то нужно. Масс-маркет. Хотя бы с этого начать.

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

Да! Сабж называется "парадигма OOP плохо ложиться на реляционные отношения...", Собсно речь о том, что формально отлично ложиться.
...
Рейтинг: 0 / 0
31.07.2015, 04:21
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39019999
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
Зимаргл,

производительность сейчас нужна только из за того что СУБД готова отвечать на ЛЮБЫЕ (99% никогда никому ненужные) запросы
запросы должны быть оструктурированы (как часть структуры - поведение) - это разумные запросы
а те 99% должен обрабатывать другие сервера НЕУСТАННО - что бы выявить РАЗУМНЫЕ запросы и их кешировать с ответами - т.е. накопить знания
ладно, ну вас
...
Рейтинг: 0 / 0
31.07.2015, 04:28
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39020001
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
U-gene,

да никто никуда плохо не ложится
рмд и ооп + еще много чего - части одной общей парадигмы, просто знания приходят по нужде
счаас пришло время их не ложить друг на друга, а синтезировать в единое целое
...
Рейтинг: 0 / 0
31.07.2015, 04:30
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39020006
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
и не так как ты это пытаешься делать - переносишь программирование на сервер :) (ведь так все и сейчас делают - только на клиенте - создают класс с собственными свойствами, коллекцию (для проекций тоже) для собственных экземпляров, навигационные коллекции (проекции) связанных классов и т.д.)
т.е. модель создается на клиенте
а ты модель и переносишь на сервер, а языка такого мощного как C# допустим не можешь дать или дашь только ОДИН, а им надо много, кто на чем привык и кроме того им все равно надо делать прокси для модели на клиенте, для проекций модели и т.д.
т.е. ты просто создаешь дополнительную СЛОЖНОСТЬ :)
решение не там
...
Рейтинг: 0 / 0
31.07.2015, 06:05
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39020183
Зимаргл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зимаргл
Гость
U-geneЗимарглВ Cache так и сделано поверх иерархического хранения.
В каше логика сосем наоборот КМК. Там одни и те же данные можно рассматривать и как таблицы и как объекты. Я бы описал это как две гомогенных схемы, которые применяются к одним и тем же данным. Плюс, когда работаем объектами, начинаются пляски типа "поднять в память", "сохранить на диск". Плюс объект хранится целиком, в моем же случае можно часть хранить, часть вычислять (это зависит от реализации, которую можно менять на ходу). А это важно, поскольку позволяет создавать схемы, которые выглядят как избыточные (в целях выразительности и красивости с точки зрения бизнеса), а при реализации от это избыточности избавляться.

ЗимарглА в целом такая система очень плохо масштабируется:
-или берем большой большой мейнфрейм и все ок
-или можно засунуть инмемори с технологией типа CoW
Насчет "очень плохо масштабируется" я не понял, с чего такой вывод. Реляционные СУБД вообще не очень масштабируются, но я же не обещаю решения всех вопросов.

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

Короче, очевидный велосипед.

Ой, нам бы ваши масштабы бггг.
Я то думаю о себе в молодости.Мне такая бы штука очень пригодилась бы для моих решений для всяких бизнесов. Да и сейчас таких как я - тысячи. Кто то возится с 1С. По нынешним ценам на память, ОЗУ недорого сервера вместит БД средне-статистического предприятия несколько раз, инмемори он или просто так. Там масштабирование и распределение не очень то нужно. Масс-маркет. Хотя бы с этого начать.

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

Да! Сабж называется "парадигма OOP плохо ложиться на реляционные отношения...", Собсно речь о том, что формально отлично ложиться.
РМД масштабируется может и не очень, но ее же теория, дает известную по затратам практику как в масштабировании, так и в конкурентной обработке данных. Для массива объектов такой теории априори нет (если не брать в расчет раскладывание объектов в РМД).

Поднять в память, сохранить на диск - ну а как без этого, персистентность то нужна.

1С отвратительный пример объектной реализации. Система которая требует памяти равной объему БД и при этом сервер все равно загибается на 100 неспешных потребителях.

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

Ок, ОЗУ у тебя хранит среднестатистическую БД. Интел сервер поддерживает сейчас порядка 2Тб ОЗУ. БД выросла, ОЗУ таки
кончилось. Что ты предлагаешь делать дальше?

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

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

ЗимарглВсе что ты хочешь есть в объектных СУБД инмемори. Выбирай для своего языка. Единственное - язык должен поддерживать интроспекцию, иначе будет неудобно. Я не хочу связываться с каким-то языком. Я не хочу иметь объекты в программе. Я хочу сложную активную модель бизнеса в БД, существующую независимо от любых внешних языков и систем. Это в объектных БД есть? КМК там все наоборот будет. SELECTы и въюхи по модели там возможны? Классы добавить/поменять на ходу можно? Объекты из класса класс пересовывать можно? Как решаются вопросы избыточности данных?

Кстати "объектных СУБД инмемори" - это что?

ЗимарглОк, ОЗУ у тебя хранит среднестатистическую БД. Интел сервер поддерживает сейчас порядка 2Тб ОЗУ. БД выросла, ОЗУ таки кончилось. Что ты предлагаешь делать дальше?
Мне кажется, вы опять что то свое в голове держите. Ну да ладно, попробую ответить.
1) Реляционные СУБД, держат в своем ОЗУ данные которые
- используются сейчас
- использовались недавно
- используются часто
Ничего не меняется. Большой объем ОЗУпредпочтительнее, потому что СУБД будет поднята в память вся, то есть не надо будет повторно "связывать" поднимаемые записи во внутренние структуры, соответствующие объектам.
2) В обычной СУБД (под той же 1С), ежели мы запустим какую-нибудь операцию над 100 документами, СУБД все записи относящиеся к этим документам так или иначе в память поднимет, что бы передать их на сервер 1С и там выполнить операцию - вне зависимости от того, насколько сложна эта операция. В моем случае для операций типа "поставить галочку 'заблокировано'" для СУБД в её памяти нужны только те записи, которые к галочке относятся.
3) Важный фактор КМК находится с другой (инфологической) стороны. Существует гетерогенная схема, где есть обычные таблицы. По факту, объекты нужны для активной, текущей части бизнеса, где правила меняются на ходу. А всякие бух.журналы,куда всё в конце концов попадает - это традиционные таблицы. Т.е. в виде объектов в среденестатистическом масс-маркетном случае будет далека не вся БД.
...
Рейтинг: 0 / 0
31.07.2015, 11:58
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39020266
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ViPRosи не так как ты это пытаешься делать - переносишь программирование на сервер :) (ведь так все и сейчас делают - только на клиенте - создают класс с собственными свойствами, коллекцию (для проекций тоже) для собственных экземпляров, навигационные коллекции (проекции) связанных классов и т.д.)
т.е. модель создается на клиенте
а ты модель и переносишь на сервер, а языка такого мощного как C# допустим не можешь дать или дашь только ОДИН, а им надо много, кто на чем привык и кроме того им все равно надо делать прокси для модели на клиенте, для проекций модели и т.д.
т.е. ты просто создаешь дополнительную СЛОЖНОСТЬ :)
решение не там
Я так сложно не думаю. И я не о системщиках программистах думаю, а о прикладниках последнего звена (кто, например, с 1С общается) и о конечных пользователях. Язык, мощный как С#? Зачем это для них?

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



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

То, что ты написал про про прокси и тд, наверное когда-нибудь нужно будет, но приоритеты другие, и в этих приоритетах я упрощаю и саму системы и способы ее управления.
...
Рейтинг: 0 / 0
31.07.2015, 12:37
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39020349
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
[quot U-geneМне будет для начала достаточно прикрутить к этой СУБД визуальный конструктор схем, что бы он на экране таблицы и классы рисовать позволял, и визуальный конструктор интерфейсов, что бы для созданной схемы окошки и отчеты клепать.



В этой схеме[/quot]
это все ВИПРОС делает (при том не нужен никакой язык)
...
Рейтинг: 0 / 0
31.07.2015, 13:18
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39020368
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ViPRos[quot U-geneМне будет для начала достаточно прикрутить к этой СУБД визуальный конструктор схем, что бы он на экране таблицы и классы рисовать позволял, и визуальный конструктор интерфейсов, что бы для созданной схемы окошки и отчеты клепать.
В этой схеме
это все ВИПРОС делает (при том не нужен никакой язык)[/quot]

ВИПРОС молодец, я уверен. Только я хочу прямо в БД, что бы не таскать туда-сюда данные, что бы СУБД, оставаясь реляционной (в соответствии с требованиями Кодда), понимала семантику более сложных структур и позволяла пользователю работать с ними. Ну я язык - универсальное ср-во управления. К нему сверху можно хоть командную строку, хоть интерфейс, хоть прокси-объекты прикрутить, нет ограничений.
...
Рейтинг: 0 / 0
31.07.2015, 13:31
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39020425
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
U-gene,

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

Я совсем перестал понимать, что же ты хочешь.

На крайний случай сообщаю - PL/SQL изобрели давным давно,объекты внутрях Оракла тоже живут - обрабатывай всю логику там же внутри сервера, никуда ничего не таская.
http://docs.oracle.com/cd/B19306_01/appdev.102/b14260/adobjint.htm

Вот визуально бизнес-логику ты там не создашь.

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

В Oracle логика совсем другая - "объекты в таблицах". Это ведет к куче лишних заморочек, например, если наследуешь UDT, то надо явно наследовать соответствующую типизированную таблицу.

Или опыт из моего общения с Постгри, где тоже есть типизированные таблицы. Я, как человек "испорченный" простой логикой, наивно полагал, что таблица есть коллекция экземпляров и все экземпляры всяко будут относится в этой коллекции. Поэтому я сделал UDF, которая принимает ссылку(как я думал) на этот экземпляр и стал его менять. Лезу в таблицу, а там ничего не поменялось. Потом оказалось, что в функцию передается копия экземпяра, и ты можешь менят ее как хочешь, но потом, будь добр, руками сделай UPDATE этой записи в таблице. То есть снова есть экземпляры в хранилище, есть экземпляры в ОЗУ и надо рукой отслеживать, что бы они друг другу соответствовали. Мне это не нравится, это чисто технологические заморочки.

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

Нашел текст по небольшому сравнению именно логики соединения ОО и РМД.

Нами реализован принципиально иной подход к объединению объектных и реляционных свойств в рамках одной системы.
- Концепции "класс" и "объект" реализованы в соответствии с ОО парадигмой программирования и максимально похоже на распространенные ОО языки. (В ОРСУБД используются "типы, определяемые пользователем", UDT).
- Все создаваемые объекты существуют как элементы своего класса и как иначе. (В ОРСУБД экземпляры UDT хранятся в типизированных таблицах, для обработки данных в ОЗУ создаются их копии)
- Объекты уникальны. Любой объект доступен по ссылке. (В ОРСУБД, экземпляры UDT-строки уникальны и доступны в пределах таблицы, а экземпляры-атрибуты, по ссылке вообще недоступны.)
- Атрибуты объектов могут быть хранимыми и вычисляемыми (В ОРСУБД атрибуты UDT всегда хранятся как атрибуты таблицы). Это позволяет создавать гораздо более гибкие схемы данных.
- Возможно множественное наследование классов. (В ОРСУБД множественное наследовании невозможно. Наследование описывается раздельно для UDT и таблиц)
- И атрибуты, и методы классов полиморфны, их реализация может меняться при наследовании. (В ОРСУБД такой полиморфизм отсутствует).
- Возможны любые операции над группой объектов, в том числе выполнение методов (В ОРСУБД групповые операции ограничиваются операциями над типизированными таблицами)
- Переход от объектного описания объектов к реляционному представлению их данных выполняется системой неявно, незаметно для пользователя при обращении к классам. (В ОРСУБД, доступ к экземплярам UDT реализован в явных операциях доступа к типизированным таблицам, но не к самим UDT.)
Возможна операция динамической реклассификации объектов(принципиально новая опция).
Подход основан на реляционной модели данных, сохраняет ее формальные свойства (ОРСУБД значительно нарушают формальные основы РМД.)
...
Рейтинг: 0 / 0
31.07.2015, 15:33
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39020610
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
этта
Гость
U-gene
Или опыт из моего общения с Постгри, где тоже есть типизированные таблицы. Я, как человек "испорченный" простой логикой, наивно полагал, что таблица есть коллекция экземпляров и все экземпляры всяко будут относится в этой коллекции. Поэтому я сделал UDF, которая принимает ссылку(как я думал) на этот экземпляр и стал его менять. Лезу в таблицу, а там ничего не поменялось. Потом оказалось, что в функцию передается копия экземпяра, и ты можешь менят ее как хочешь, но потом, будь добр, руками сделай UPDATE этой записи в таблице. То есть снова есть экземпляры в хранилище, есть экземпляры в ОЗУ и надо рукой отслеживать, что бы они друг другу соответствовали.
1. нет никакого постгри. есть "постгрес, куяль". это справка.

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

1) Ой сорри бггг. Но так привык, люди понимают, и даже ихние спецы оттуда не обижаются так сильно.
2) Там другие моменты тоже печальны бесконечно. Потому что делалось в спешке, на волне пика интереса к ООСУБД, КМК чисто что бы показать, что "у нас тоже есть". Натянули ООП в лоб на таблицы, и получили по сути те же таблицы, только с другим названием и кучей вопросов "зачем?" и "нафига?". В названии буковка "О" стоит, но в мануалах аккуратно про UDT и про типизированные таблицы (то есть объектов и классов нет).

Поэтому этим и не пользуется никто.
...
Рейтинг: 0 / 0
31.07.2015, 16:34
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39020670
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
этта
Гость
U-gene,
ой, а вы всё со списанной торбочкой ООБД своей нодоноситесь.
год десятый почитай недонашиваете. бггг. узнаю брата колю

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

Опять ООБД.... и г-на побольше накинуть анонимно.

Десять лет... да даже побольше, наверное... сначала теорию прорабатывал, потом прототип лепил, щас уже в плане внедрения стою.

Крутизна Постгри.... бгггг.... пусть они сначала наследование таблиц доделают не для галочки, а что бы можно было пользоваться, лет десять обещают.

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

В общем, тьфу на тебя.
...
Рейтинг: 0 / 0
31.07.2015, 17:11
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39020724
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
этта
Гость
U-gene,

чота сильно бомбануло
дышите глубже, поциент
за вами никто не охотится


и да, я хуже ...ээ, можете не сомневаться. по меркам ...ээ.
хехе.
...
Рейтинг: 0 / 0
31.07.2015, 17:36
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021029
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ScareCrow
Участник
авторЧто самое забавное - по большому счету этот принцип "лОжения ООП на отношения" давным-давно используются кучей систем (тех же бизнес- систем, тем же 1С), которые собирают свои объекты из разных строк разных таблиц. Однако они таскают данные из БД, но ведь никто не мешает пойти в другую сторону - оставить данные в СУБД, а заставить её обрабатывать команды, работающие с такими объектами. Мне удивительно, это же очевидно, почему этого никто не видит?

тормозит. да и писать сложно.
...
Рейтинг: 0 / 0
01.08.2015, 18:41
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021083
Зимаргл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зимаргл
Гость
ScareCrowавторЧто самое забавное - по большому счету этот принцип "лОжения ООП на отношения" давным-давно используются кучей систем (тех же бизнес- систем, тем же 1С), которые собирают свои объекты из разных строк разных таблиц. Однако они таскают данные из БД, но ведь никто не мешает пойти в другую сторону - оставить данные в СУБД, а заставить её обрабатывать команды, работающие с такими объектами. Мне удивительно, это же очевидно, почему этого никто не видит?

тормозит. да и писать сложно.
вот как раз не угадал.
на стороне сервера обрабатывать гораздо быстрее, чем таскать данные и результаты сквозь кучу драйверов, ОРМ и сеть.
писать программу тоже легче без прослоек в виде АПИ.
а вот сопровождать хуже и не дай бог сменится парадигма логики.

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

что тормозит, не понимаю?
В обычной системе что бы обработать условную сотню объектов, клиент или апп.сервер генерит условную тыщу простых запросов (что бы достать данные их БД), СУБД их парсит, выполняя для каждого кучу работы, отдает данные по кусочку, апп.сервер обрабатывает их и другой тыщей запросов возвращает в БД. И это все в транзакции. А еще (как писал ViPRos), будучи в этой транзакции, СУБД не знает, что там будет дальше (потому что смыслы данных и логика обработки от сервера скрыты) поэтому фигакс и зависли (если рядом кто-то что-то похожее делать пытается).
Это ли не "тормозит"?
...
Рейтинг: 0 / 0
03.08.2015, 07:29
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021388
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Зимаргл при нормальном проектировании уже давно поставили под сомнение, что ООП всегда дает выгоду в разработке, СУБД не исключение.У меня ООП не must, a can.
...
Рейтинг: 0 / 0
03.08.2015, 07:31
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021389
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
да отлично ложится. Не верьте никому.
...
Рейтинг: 0 / 0
03.08.2015, 07:37
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021533
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ScareCrow
Участник
U-geneScareCrow,

что тормозит, не понимаю?


попытка натянуть объекты на реляционные данные тормозит. типичная дырявая абстракция, поэтому и не прижилась.
...
Рейтинг: 0 / 0
03.08.2015, 11:32
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021537
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Парадигма ООП и на плоские текстовые файлы плохо ложится. Но это не мешает куче людей
сериализовать туда свои объекты и считать, что это круто. Называют эту фигню красивыми
словами типа XML или JSON и радуются как дети. Глупые они, наверное.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.08.2015, 11:34
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021626
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ScareCrow
Участник
а СУБД им тогда зачем?
...
Рейтинг: 0 / 0
03.08.2015, 12:49
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021633
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ScareCrowа СУБД им тогда зачем?
И вот это - очень хороший вопрос.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.08.2015, 12:54
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021655
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tanglir
Участник
Потому что текстовые файлики - как-то несолидно, а какую-то свою "оригинальную" систему хранения написать не получается?
...
Рейтинг: 0 / 0
03.08.2015, 13:14
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021690
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ScareCrow
Участник
tanglirПотому что текстовые файлики - как-то несолидно, а какую-то свою "оригинальную" систему хранения написать не получается?

Redis или мемкеш. за глаза.
...
Рейтинг: 0 / 0
03.08.2015, 13:35
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021756
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
парадигму ООП компилятор превращает в таблички , а таблички вотчина РМД
...
Рейтинг: 0 / 0
03.08.2015, 14:35
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021775
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Dimitry SibiryakovПарадигма ООП и на плоские текстовые файлы плохо ложится. Но это не мешает куче людей
сериализовать туда свои объекты и считать, что это круто. Называют эту фигню красивыми
словами типа XML или JSON и радуются как дети. Глупые они, наверное.


Добавлю, что и реляционные данные на линейную память и файлы (а именно так работают компы), тоже в лоб не положишь. Поэтому понавыдумывали кешей, методов доступа, дветыщивосемьсятпять видов индексов, итди тп, что бы хоть как то положить.
...
Рейтинг: 0 / 0
03.08.2015, 14:54
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021786
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
U-gene,

все дело в том, что не ДАННЫЕ (объекты) надо положить в РМД, а саму объектную парадигму(???? - хрень какая та)
ну ты до всего этого уже своим умом дошел за 10 лет :)
а с другими говорить на эьту тему бесполезно - надо все это через себя пропускать (или кому то надо написать новый манифест :), мне некогда)
...
Рейтинг: 0 / 0
03.08.2015, 15:02
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021936
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ScareCrow
Участник
автордветыщивосемьсятпять видов индексов
я только про три знаю.
...
Рейтинг: 0 / 0
03.08.2015, 17:07
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39021986
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
ViPRosпарадигму ООП компилятор превращает в таблички , а таблички вотчина РМД
Вообще-то РМД это логическая МД. И потому таблички полученные компилятором, как бы не совсем вотчина РМД, скорее всего. Так как полученное компилятором это физика, которая должна быть черным ящиком для логики. Иначе зачем появились СУБД как не позволить нам заниматься только логикой?
...
Рейтинг: 0 / 0
03.08.2015, 17:52
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39022064
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
vadiminfoViPRosпарадигму ООП компилятор превращает в таблички , а таблички вотчина РМД
Вообще-то РМД это логическая МД. И потому таблички полученные компилятором, как бы не совсем вотчина РМД, скорее всего. Так как полученное компилятором это физика, которая должна быть черным ящиком для логики. Иначе зачем появились СУБД как не позволить нам заниматься только логикой?
у компилятора это тоже "логическая табличка" - физических таблиц то и не существует
...
Рейтинг: 0 / 0
03.08.2015, 19:35
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39022239
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
Люди вы о чем. ООП плохо ложиться на Реляционную модель, потому что таблички со детерминированными связями между ними хорошо реализуют инкапсуляцию, с наследованием и полиморфизмом слегка сложнее. Технически надо реализовывать ТВМ (VMT) и иже и логику работы с ними запихивать во вьюшки. Т.е. кому-то (програмисту или ORM) придется реализовывать их вместо нативной. Это резко добавляет накладных расходов.
...
Рейтинг: 0 / 0
04.08.2015, 08:28
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39022423
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Сергей Арсеньев,

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

Типичный пример ненужного самоограничения . А если еще знать про Oracle, PostgreSQL и т.п. авторитетах, одевших те же шоры десятилетия назад, то, наверное, любые попытки думать в альтернативном направлении просто не воспринимаются, сознание упрямо впихивает объект в таблицу, и, как результат, видит проблемы, которые в альтернативе не существуют.
...
Рейтинг: 0 / 0
04.08.2015, 12:09
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39022429
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ScareCrowавтордветыщивосемьсятпять видов индексов
я только про три знаю.

2085 - это мое любимое числительное, обозначающее от "нескольких" до "очень много" :)

Например, http://habrahabr.ru/post/102785/
...
Рейтинг: 0 / 0
04.08.2015, 12:12
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39022475
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ViPRosU-gene,
все дело в том, что не ДАННЫЕ (объекты) надо положить в РМД, а саму объектную парадигму(???? - хрень какая та)


Таки я тут писал, ООП - это не про МД, а про переход от одной МД к другой, о конструировании новых, не существующих в исходной МД типов. Программист конструирует новые типы, пользователь пользуется объектами.В традиционных ОО языках объекты конструируются как совокупность переменных базовых типов, это КМК единственно возможно.

Точно так же, раз в РМД есть домены и есть отношения, надо конструировать объекты как совокупность переменных доменных и табличных типов. Так их давным-давно во всех бизнес-системах конструируют (например, условный объект класса "накладная"). То есть в плане "как положить ООП в отношения" я фундаментально ничего нового не выдумал, я скорее про то, что это правильно реализовать внутри СУБД (не таская данные из/в нее), плюс некоторые новые логические плюшки.
...
Рейтинг: 0 / 0
04.08.2015, 12:33
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39025021
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ScareCrow
Участник
U-geneScareCrowпропущено...

я только про три знаю.

2085 - это мое любимое числительное, обозначающее от "нескольких" до "очень много" :)

Например, http://habrahabr.ru/post/102785/

уровень аргументации просто космический.
...
Рейтинг: 0 / 0
07.08.2015, 13:41
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39025032
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ScareCrowU-geneпропущено...


2085 - это мое любимое числительное, обозначающее от "нескольких" до "очень много" :)



уровень аргументации просто космический.
ну.. .по ссылке больше чем 3 индекса (по крайней мере 4 ... или больше? бггг)
А "дветышивосемьсятпять" - чисто по приколу.
...
Рейтинг: 0 / 0
07.08.2015, 13:56
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39025034
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
vadiminfoViPRosпарадигму ООП компилятор превращает в таблички , а таблички вотчина РМД
Вообще-то РМД это логическая МД. И потому таблички полученные компилятором, как бы не совсем вотчина РМД, скорее всего. Так как полученное компилятором это физика, которая должна быть черным ящиком для логики. Иначе зачем появились СУБД как не позволить нам заниматься только логикой?

Вчитался, отличный вопрос.
КМК ОО парадигма местами ближе к существующей физике, чем полностью ассоциатиная РМД. Именно поэтому можно опустить мое толкование объектов прямо в физику. только сделав вид , что соблюдена логика.
...
Рейтинг: 0 / 0
07.08.2015, 14:01
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39025311
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
tanglirПотому что текстовые файлики - как-то несолидно, а какую-то свою "оригинальную" систему хранения написать не получается?
Получается. После чего, они бегают с новой, МЕГА, СУПЕР, СОВРЕМЕННОЙ идеей... NO SQL. Типа база данных, которая SQL делать не умеет и это КРУТО.
...
Рейтинг: 0 / 0
07.08.2015, 18:53
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39025654
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ScareCrow
Участник
автору.. .по ссылке больше чем 3 индекса (по крайней мере 4 ... или больше? бггг)
ну ты посчитай сначала, потом найди отличия потом еще раз посчитай.
...
Рейтинг: 0 / 0
09.08.2015, 00:59
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39026001
Фотография BusInt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
BusInt
Участник
Все просто - ООП не нужно!
...
Рейтинг: 0 / 0
10.08.2015, 10:01
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39026717
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
BusIntВсе просто - ООП не нужно!

ООП нужно!
Т.к. позволяет говнокодить гораздо быстрее, чем ФП!
<:o)
...
Рейтинг: 0 / 0
11.08.2015, 06:20
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39027784
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
U-geneПро такие высказывания и написано в стартовом посте "КМК проблема исключительно в зашоренности, которая проявляется в том, что объект пытаются так или иначе воткнуть внутрь одной таблицы (как строку, или как поле строки)."

Мы говорим о парадигмах ООП? В том числе об инкапсуляции?
Да технически это можно реализовать не впихивая в одно место, но тогда мы клали болт на ООП. Вопрос именно в том, что у реляционной модели одни подходы к представлению данных, у ООП другие. Внутре, объекты ООП представляют собой те же таблицы данных и методов. Но выглядит он для программиста единым целым.
Кроме того ООП делает вид, что позволяет иные связи между данными, чем сравнение только самих полей объектов - там идут в ход связи по метаданным.

U-gene Если думать внутри этих шор, то поневоле начнешь рассуждать о наследовании таблиц и т.п. непонятных мне вещах.

Вопрос в том и состоит, почему ООП плохо ложиться на Реляционную модель.
Он потому и плохо ложиться, что требует разных взглядов. Реализовать одно, через другое можно. Но и будет требовать выполнения той работы, которую обычно скрывает компилятор. И часть операций будет делаться не эффективно, ибо инструмент заточен на иное.

U-geneА если еще знать про Oracle, PostgreSQL и т.п. авторитетах, одевших те же шоры десятилетия назад, то, наверное, любые попытки думать в альтернативном направлении просто не воспринимаются, сознание упрямо впихивает объект в таблицу, и, как результат, видит проблемы, которые в альтернативе не существуют.
Упрямо впихивают пользователи. Ибо РСУБД относительно быстры и вездесущи. В том же Oracle можно хранить объекты. Правда это почти никому нафиг не сдалось.

Вопрос в том, что если не использовать механизмы навигации СУБД. А делать это на стороне прикладного приложения, то реляционная модель и вовсе не вперлась - используй СУБД пключ-значение и все пучком. Но может оказаться, что придется таскать кучу объектов для того, чтобы найти два связанных. И все придется делать самому. Вот все и хотят и рыбку съесть... Т.е. чтобы и СУБД работала на фильтрах и самому объектами вальяжно оперировать.
...
Рейтинг: 0 / 0
12.08.2015, 13:00
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39027850
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
Сергей Арсеньев Вопрос в том, что если не использовать механизмы навигации СУБД. А делать это на стороне прикладного приложения, то реляционная модель и вовсе не вперлась - используй СУБД пключ-значение и все пучком. Но может оказаться, что придется таскать кучу объектов для того, чтобы найти два связанных. И все придется делать самому. Вот все и хотят и рыбку съесть... Т.е. чтобы и СУБД работала на фильтрах и самому объектами вальяжно оперировать.

IMHO "парадигма OOP плохо ложиться на реляционные отношения" потому что повсеместно используются ORM.
Если же "отделять мух от котлет", то все нормально.
Данные хранятся в БД, которые запросами вытаскиваются в объекты.

ORM же берет все худшее от двух миров.
С одной стороны не позволяет использовать всю мощь ООП, с другой ограничивает декларативный язык SQL.
Если же "забыть" про ORM, то все становится на свои места.
Используя мощь SQL мы можем вытащит данные в том виде как нам удобно.
И это не ограничивает в написании бизнес-логики на ООП.
...
Рейтинг: 0 / 0
12.08.2015, 13:51
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39027854
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
mad_nazgulИспользуя мощь SQL мы можем вытащит данные в том виде как нам удобно.
И это не ограничивает в написании бизнес-логики на ООП.
Мы и не говорим об ограничении бизнес-логики.
Просто "плохо ложится". Это и означает, что забывать про ООП при общении с базой действительно легче, чем заставить РМ танцевать под дудку ООП.
...
Рейтинг: 0 / 0
12.08.2015, 13:55
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39027932
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
Сергей Арсеньевmad_nazgulИспользуя мощь SQL мы можем вытащит данные в том виде как нам удобно.
И это не ограничивает в написании бизнес-логики на ООП.
Мы и не говорим об ограничении бизнес-логики.
Просто "плохо ложится". Это и означает, что забывать про ООП при общении с базой действительно легче, чем заставить РМ танцевать под дудку ООП.

"Смешались в кучу..."

SQL - это декларативный подход, как минимум так проектировался.
Грубо говоря мы формулируем что нам нужно получить, а ЯП сам решает как это сделает.
ООП работает в рамках императивного подхода.
Т.е. мы должны не только знать что нам надо, но и как это получить.
Т.к. ИИ нет, то декларативный подход имеет множество ограничений.
В частности смогли более менее его реализовать на РМД.
Более общий декларативный подход не осилили (см. Prolog).

Если "статичные" данные более-менее укладываются в РМД, то уже такие вещи как бизнес-логика и бизнес-процесс в РМД ложатся очень трудно.
Т.е. в БД нужно хранить только данные, а все остальное выносить на уровень приложения.
И объекты уж точно нельзя хранить в БД, только данные для объектов.

А уж ООБД и NoSQL это химеры.
Предназначенные для "честного отъема денег у населения"

<:o)
...
Рейтинг: 0 / 0
12.08.2015, 15:07
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39027947
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
mad_nazgul,

никакой декларативности в СКЛ нет
Селект требует Фром, Джойн, Юнион - т.е. требует всю навигационную информацию
когда такая инфа есть, то любо дурак может сгенерировать цикл выборки
т.е. СКЛ - просто синтаксический сахар
...
Рейтинг: 0 / 0
12.08.2015, 15:16
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39027964
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
mad_nazgul,

Прежде чем смешивать, где Вы увидели слова про SQL?
Мы про Реляционную модель и принципы ООП. Про способы реализации оных только абстрактно.
В целом вопрос звучит так. Почему приходится думать по разному при работе в ООП и РМ.
Т.е. всякие ОRМ это могут и за людей, но как то коряво. :)
...
Рейтинг: 0 / 0
12.08.2015, 15:30
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39028003
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
этта
Гость
ViPRosmad_nazgul,

никакой декларативности в СКЛ нет
Селект требует Фром, Джойн, Юнион - т.е. требует всю навигационную информацию
когда такая инфа есть, то любо дурак может сгенерировать цикл выборки
т.е. СКЛ - просто синтаксический сахар
таки любой дурак запутался в 3-х соснах

скл -- это именно декларации
но декларации над плоскими отношениями, которые "любой дурак" умеет превращать в цыклы.
вся якобы навигационщина -- декларативные сказания о множествах.
быть может за исключением order by LIMIT offset -- тут уже немного прямой нафигации]

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

что кладется в РМД кучки -- то и обрабатывается простыми и не очень трансляторами деклараций в инструкции. что нет -- то и нет.

поленился разложить -- имей дело с неформализованной хренью, о которой никаких трансляторов нетути.
...
Рейтинг: 0 / 0
12.08.2015, 16:20
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39028037
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
эттаViPRosmad_nazgul,

никакой декларативности в СКЛ нет
Селект требует Фром, Джойн, Юнион - т.е. требует всю навигационную информацию
когда такая инфа есть, то любо дурак может сгенерировать цикл выборки
т.е. СКЛ - просто синтаксический сахар
таки любой дурак запутался в 3-х соснах

скл -- это именно декларации
но декларации над плоскими отношениями, которые "любой дурак" умеет превращать в цыклы.
вся якобы навигационщина -- декларативные сказания о множествах.
быть может за исключением order by LIMIT offset -- тут уже немного прямой нафигации]

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

что кладется в РМД кучки -- то и обрабатывается простыми и не очень трансляторами деклараций в инструкции. что нет -- то и нет.

поленился разложить -- имей дело с неформализованной хренью, о которой никаких трансляторов нетути.
хреновая это декларация
...
Рейтинг: 0 / 0
12.08.2015, 16:59
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39028042
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CawaSPb
Участник
Какой сра.. дисскуссию пропустил!

Подливая масла в огонь:
http://martinfowler.com/bliki/OrmHate.html

Ну и конечно же упоминаемая там же классика:
http://blogs.tedneward.com/2006/06/26/The Vietnam Of Computer Science.aspx
...
Рейтинг: 0 / 0
12.08.2015, 17:04
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39028262
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
ViPRosхреновая это декларация

Какая есть.
Для другой нужен ИИ. :-)
...
Рейтинг: 0 / 0
13.08.2015, 06:05
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39028704
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Сергей Арсеньев ...Вопрос именно в том, что у реляционной модели одни подходы к представлению данных, у ООП другие.
...

Я не понимаю. какие-такие у собственно ООП есть "подходы к представлению данных".

Объясню на примере. Используя какой-нибудь ООЯ я могу создать разные объекты с разным представлением данных. Например я могу реализовать класс "Таблица" и два его подкласса "ХранимаяТаблица" и "Вид". Для класса "Таблица" я сделаю разные методы, например метод "Проекция", который будет принимать у меня набор имен, и выдавать новый объект класса "Таблица". То есть эти мои объекты будут моделировать реляционное хранилище в соответствии с РМД.

Вопрос. В этом примере какое представление данных получилось - объектное или реляционное?

Ответ. ООП - очень важная штука, но это не модель данных, которая задает какое-то определённое, как Вы сказали, "представление данных". Модель - это набор типов, переменные которых интересны пользователю. Это может быть переменная типа "строка", или типа "реляционное отношение", или типа "Накладная" или что то еще. То есть каждый раз речь идет о какой-то новом наборе типов, то есть, по факту, о новой модели. Это может быть реализация обще-формальной модели как РМД, или чего то очень специфического.

ООП - очень важная штука, потому что изначально в инф. системах мы имеем очень ограниченный набор простых типов. а ООП - универсальная парадигма того, как из такого ограниченного набора простых типов можно построить любой тип. ООП не имеет собственного "представления данных", зато позволяет реализовать любое нужное представление. Это не модель, это парадигма перехода от одной модели к другой, вообще говоря ортогональная любой МД.

Поэтому сравнивать ООП И РМД по их "представлениям данных" некорректно, ибо сравнивать нечего.

Кстати, собственных операция над данными в ООП тоже нет. По этому пункту она тоже - не МД.

Если у Вас есть другой ответ на мой впрос по примеру, давайте. Только, ради бога, не надо словоблудий, обходитесь простыми, понятными терминами, типа "тип", "переменная", "операция", "модель данных"(по Кодду, а не просто так), "схема данных" и т.п. Как только начинаешь их понимать и использовать, сразу многое в голове проясняется и становится на свои места.

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

И в конце концов мне кааца, Вы о чем-то своем спорите, аргументируя какими то прикладными приложениями, где, видимо, живут объекты, которые, видимо, надо запихнуть в БД. Нет у меня этого.
...
Рейтинг: 0 / 0
13.08.2015, 14:40
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39028721
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
mad_nazgul
"Смешались в кучу..."

SQL - это декларативный подход, как минимум так проектировался.
Грубо говоря мы формулируем что нам нужно получить, а ЯП сам решает как это сделает.
ООП работает в рамках императивного подхода.
Т.е. мы должны не только знать что нам надо, но и как это получить.
Т.к. ИИ нет, то декларативный подход имеет множество ограничений.
В частности смогли более менее его реализовать на РМД.
Более общий декларативный подход не осилили (см. Prolog).

Если "статичные" данные более-менее укладываются в РМД, то уже такие вещи как бизнес-логика и бизнес-процесс в РМД ложатся очень трудно.
Т.е. в БД нужно хранить только данные, а все остальное выносить на уровень приложения.
И объекты уж точно нельзя хранить в БД, только данные для объектов.

А уж ООБД и NoSQL это химеры.
Предназначенные для "честного отъема денег у населения"

<:o)

Тоже смешались в кучу :) Вы постоянно путаете сами концепции и существующие реализации этих концепций.

Существующие реализации ООП работают в рамках императивного подхода, ибо создавались как развитие средств программирования. В самой ООП нет не слова ни про императивность ни про декларации.

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

CawaSPbПодливая масла в огонь:
http://martinfowler.com/bliki/OrmHate.html

Ну и конечно же упоминаемая там же классика:
http://blogs.tedneward.com/2006/06/26/The Vietnam Of Computer Science.aspx
И я подливаю , подливаю .
...
Рейтинг: 0 / 0
13.08.2015, 15:04
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39028763
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
BusIntВсе просто - ООП не нужно! Тока не так категорично. Но согласен, существующие реализации ООП местами приносят больше граблей, чем пользы.
...
Рейтинг: 0 / 0
13.08.2015, 15:25
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39028923
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
U-geneВопрос. В этом примере какое представление данных получилось - объектное или реляционное?

Встречный вопрос у топиккастера - почему ООП плохо ложиться на РМ? Вопрос как РМ переложить на ООП из другой оперы.
Придумать нечто урезанное до того, что легко вписывается в те и другие рамки, тоже не ответ на первоначальный вопрос.
Это мы еще не рассматривали ООП в терминах прототипирования (а не наследования) с динамической сменой цепочки прототипов.
...
Рейтинг: 0 / 0
13.08.2015, 17:09
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39028950
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Сергей Арсеньев Встречный вопрос у топиккастера - почему ООП плохо ложиться на РМ? Вопрос как РМ переложить на ООП из другой оперы.
Придумать нечто урезанное до того, что легко вписывается в те и другие рамки, тоже не ответ на первоначальный вопрос.
Это мы еще не рассматривали ООП в терминах прототипирования (а не наследования) с динамической сменой цепочки прототипов.

Не надо уходить от ответа.
Я дал совершенно четкий пример и задал очень понятный вопрос по непонятному мне "представлению данных" в ООП Это не "встречный" вопрос, а лишь попытка понять, о чем Вы вообще говорите. Также я объяснил, почему никакого "представления данных" в ООП вообще нет (видимо Вы этого не поняли, раз пишете про "и те и другие рамки").
...
Рейтинг: 0 / 0
13.08.2015, 17:33
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39028999
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
U-gene,

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

Сергей АрсеньевU-gene,

Мы говорим о том, что часть парадигм составляющих ООП плохо представимы в виде РМ.
Если же пытаться напрямую сбросить это в базу, не задумываясь, что хорошо для РМ, а что плохо, то каким бы ни был умным ОРМ возникают сложности.

А я не говорю "о том, что часть парадигм составляющих ООП плохо представимы в виде РМ." У меня все базовые парадигмы очень даже представимы. И вообще, что такое "плохо"? Мы же говорим о формальных вещах, там либо ""представимы" либо "не представимы".

Какой ОРМ? Откуда Вы ОРМ то взяли? Я ж говорю , что Вы о чем то своем поёте. Нету никакого ОРМа, забудьте же про это. ОРМ - это когда какая-то реализация ООП в системе с линейной памятью отображается в реляционную память, а у меня речь идет о реализация ООП в системе с реляционной памятью , там в принципе маппинга нет, данные уже там где нужно и в каком надо виде.

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

Кстати, мы же не говорим, что"часть парадигм, составляющих ООП плохо представимы в виде" линейной памяти.

Вы таки помедитируйте о чем я говорю. :)
...
Рейтинг: 0 / 0
13.08.2015, 21:29
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39029145
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
U-geneТоже смешались в кучу :) Вы постоянно путаете сами концепции и существующие реализации этих концепций.

Существующие реализации ООП работают в рамках императивного подхода, ибо создавались как развитие средств программирования. В самой ООП нет не слова ни про императивность ни про декларации.

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

Давайте пофлудим о парадигмах.
Давным давно ЯП делили на императивные и декларативные.
Причем императивные считали "устаревшими", а за декларативными видели будущее.

Так вот ООП ЯП работают в рамках императивного подхода, потому что это и есть императивные ЯП.
Он проектировались как императивные ЯП, и создавались как императивные ЯП и работают как императивные ЯП.
См. первый ООП ЯП SmallTalk.

А вот с декларативными ЯП вышла промашка.
Для того, чтобы создать декларативный ЯП нужна "машина вывода".
Т.е. ядро, которое по "хотелкам" выдаст результат.
Единственное решение которое "состоялось" это был SQL.
Т.к. "ядром" для него была РМД.
Очень простая "машина вывода", которая имела предсказуемое время решения.

Тот же Prolog не взлетел из-за того, что можно было "влететь" в комбинаторный взрыв и "привет вселенная".
Т.е. кроме как лабораторных опытов не годился.

Но т.к. в РМД в лучшем случае хорошо "ложатся" только данные, то различные РСУБД начали включать в себя "императивщину".
Например psql или TSQL. Чтобы пользы от СУБД было чуть больше, т.к. голая РМД может только ограниченный круг задач.
...
Рейтинг: 0 / 0
14.08.2015, 06:44
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39029793
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
mad_nazgulТак вот ООП ЯП работают в рамках императивного подхода, потому что это и есть императивные ЯП.
Хм. Всё-таки объектность и декларативность вполне себе ортогональны. Какой из принципов ООП не совместим с декларативностью?Scala вполне себе объектная и декларативная.
...
Рейтинг: 0 / 0
14.08.2015, 21:00
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39029799
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Вот соглашусь с безумным назгулом - не надо напяливать ООП на РМД только потому, что это можно сделать.
...
Рейтинг: 0 / 0
14.08.2015, 21:12
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39029885
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
mad_nazgul,

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

А Вы, я гляжу, знаток, дааа. Извините за следующий вопрос. Правильно я понял, что Вы РМД назвали машиной вывода?
...
Рейтинг: 0 / 0
15.08.2015, 04:10
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39029886
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Basil A. SidorovВот соглашусь с безумным назгулом - не надо напяливать ООП на РМД только потому, что это можно сделать. Так напялено уже давным-давно. Принцип напяливания давным-давно используется в куче систем (в том же 1С). Почему бы его не формализовать и не запихнуть в СУБД?
...
Рейтинг: 0 / 0
15.08.2015, 04:17
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39029996
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
этта
Гость
U-gene<> Так напялено уже давным-давно. Принцип напяливания давным-давно используется в куче систем (в том же 1С). Почему бы его не формализовать и не запихнуть в СУБД?
патамушта в РСУБД есть штуки, которые нужны вчера, и которые делать лень [и неясно как]. даже за большие дэнги


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

вот это вот всё гораздо нужнее банального орм-ирования, чем тот же 1С занят. (маппинг -- полезная подпорка для ленивых, но всегда тупее рук пряморукого скл-кодера)

именно поэтому, кстати, дальше ОО--манифестации постгрес и не пошёл -- потому, что
а. никому не надо, кроме фриков с "ООП головного мозга"
б. не ясно, как сделать, чтобы хоть кому--то понадобилось для дела

а как дысали -- множественное наследование нарисовали -- не чуй собачий...
...
Рейтинг: 0 / 0
15.08.2015, 14:20
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39030037
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
U-geneBasil A. SidorovВот соглашусь с безумным назгулом - не надо напяливать ООП на РМД только потому, что это можно сделать. Так напялено уже давным-давно. Принцип напяливания давным-давно используется в куче систем (в том же 1С). Почему бы его не формализовать и не запихнуть в СУБД?
потому что сразу потеряется основной козырь - "n транзакций в секунду"
...
Рейтинг: 0 / 0
15.08.2015, 16:52
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39030041
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
РМД, ЯП универсальные - это возможность любой тупоте сотворить хоть что нить
а ООП на базе РМД убивает половину этих возможностей, так как РМД с его вседозволенным языком становится недоступна тупарям, тут уже надо думать о модели, а не методом тыка селектить хоть что нить из кое как слепленных табличек
порог становится выше для проектирования, а доходы вендоров падают
...
Рейтинг: 0 / 0
15.08.2015, 16:59
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39030121
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
ViPRosРМД, ....- это возможность любой тупоте сотворить хоть что нить
Вы еще упускаете из виду - любой тупоте достаточно просто извлечь достаточно сложную инфу из БД. Это существенно укрепляет потребность в РМД.
...
Рейтинг: 0 / 0
15.08.2015, 21:51
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39030186
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ViPRosU-geneпропущено...
Так напялено уже давным-давно. Принцип напяливания давным-давно используется в куче систем (в том же 1С). Почему бы его не формализовать и не запихнуть в СУБД?
потому что сразу потеряется основной козырь - "n транзакций в секунду" не понял
...
Рейтинг: 0 / 0
16.08.2015, 06:20
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39030827
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
эттаа. никому не надо, кроме фриков с "ООП головного мозга"
б. не ясно, как сделать, чтобы хоть кому--то понадобилось для дела


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

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

Люди, которые удосужились ознакомиться и въехать в мои материалы, практически всегда утверждают, что это решение в плане выразительности и гибкости превосходит 1С, при том, что речь идет о бизнес-модели, существующей на уровне СУБД| что делает пользовательские решения проще, резко снижает трафик и облегчает интеграцию с третьими системами. Хотя большинство считают, что знают всё, предпочитают тратить время на пустые споры.
...
Рейтинг: 0 / 0
17.08.2015, 15:29
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39030983
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Всю жизнь мечтал, чтобы разработчики при каждом обновлении перелопачивали ВСЮ базу.
А то скучно всё, динамизму нет, стремительные домкраты не падают ....
...
Рейтинг: 0 / 0
17.08.2015, 17:18
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39031272
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
Basil A. Sidorov,

А процедуру безостановочного апгрейда проводить не пробовал?
Чтоб старые запущенные сессии думали, что они работают со старой версией БД, новые с новой и это была бы одна и та же версия БД. Вот где грабли в три ряда. :)
...
Рейтинг: 0 / 0
18.08.2015, 09:09
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39039311
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Ну че, легла уже?
...
Рейтинг: 0 / 0
30.08.2015, 13:36
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39039421
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
MasterЗИВ,

Давно уже. Просто в пласт лежит, но, пока, концептуально.

Практически же, что бы вопросы снять, нужна эффективная реализация. Народу нужно прочухать фишку на практике, КМК она многим нужна ( я и по себе сужу, и здесь в форумах рядом часто о чем то подобном спрашивают). Общие идеи такой эффективной реализации понятны, но их приложение к конкретному коду требует системщиков, которые очень хорошо ориентируются в ядре конкретной СУБД (желательно PG, поскольку сам я пытаю изнутри именно эту СУБД), хотя бы на уровне консультаций.
...
Рейтинг: 0 / 0
30.08.2015, 22:01
| Ответить | Цитировать | Написать  
парадигма OOP плохо ложиться на реляционные отношения...?
    #39039445
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
этта
Гость
U-geneжелательно PG, поскольку сам я пытаю изнутри именно эту СУБДтаки для ваших экзерсисов транзакционный ддл пж подходит больше, чем близкий серцу мсскл, с которого вы стартовали ?

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

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

так же и у меня - для доказательств голой теории подходит любая реляционная СУБД. А эффективная реализация требует влезть в физику ядра, на уровень, где существуют страницы, локи, пины, структуры, указатели на структуры, кое-что добавить, немного расширить каталог и т.д. Для этого, для начала, надо иметь доступ к коду СУБД. У Вас есть доступ к коду MSSQL? Я б может даже рад был бы, ибо бизнесу решения от MS до сих пор ближе. А у PG код открыт, архитектурно то, что я успел о нем узнать, мне нравится, по сравнению с другим опенсорсом. Но принципиальной разницы, MS или PG для меня нет.

Кстати, я не понял, что, у PG DDL более "транзакционен" чем у MS? Как "транзакционность" меряется? Хотя это к делу не особо относится.
...
Рейтинг: 0 / 0
31.08.2015, 04:17
| Ответить | Цитировать | Написать  
108 сообщений из 108, показаны все 5 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / парадигма OOP плохо ложиться на реляционные отношения...?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=35&tid=1552313]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 40ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 139ms
get tp. blocked users:
 1ms
others: 10ms
total:  231ms
созд. / загр.: 231ms
x
x
Закрыть


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