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

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

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

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

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

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

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

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

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

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


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

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

Да! Сабж называется "парадигма OOP плохо ложиться на реляционные отношения...", Собсно речь о том, что формально отлично ложиться.
31 июл 15, 04:21    [17958096]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
ViPRos
Member

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

производительность сейчас нужна только из за того что СУБД готова отвечать на ЛЮБЫЕ (99% никогда никому ненужные) запросы
запросы должны быть оструктурированы (как часть структуры - поведение) - это разумные запросы
а те 99% должен обрабатывать другие сервера НЕУСТАННО - что бы выявить РАЗУМНЫЕ запросы и их кешировать с ответами - т.е. накопить знания
ладно, ну вас
31 июл 15, 04:28    [17958099]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
ViPRos
Member

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

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

Откуда:
Сообщений: 9967
и не так как ты это пытаешься делать - переносишь программирование на сервер :) (ведь так все и сейчас делают - только на клиенте - создают класс с собственными свойствами, коллекцию (для проекций тоже) для собственных экземпляров, навигационные коллекции (проекции) связанных классов и т.д.)
т.е. модель создается на клиенте
а ты модель и переносишь на сервер, а языка такого мощного как C# допустим не можешь дать или дашь только ОДИН, а им надо много, кто на чем привык и кроме того им все равно надо делать прокси для модели на клиенте, для проекций модели и т.д.
т.е. ты просто создаешь дополнительную СЛОЖНОСТЬ :)
решение не там
31 июл 15, 06:05    [17958143]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
Зимаргл
Guest
U-gene
Зимаргл
В Cache так и сделано поверх иерархического хранения.

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

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

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

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

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


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

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

Да! Сабж называется "парадигма OOP плохо ложиться на реляционные отношения...", Собсно речь о том, что формально отлично ложиться.

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

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

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

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

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

"парадигма OOP плохо ложиться на реляционные отношения...". Да - хранить объекты формально хорошо, но работать с ними медленно - сложные запросы, тяжелые транзакции. Это хорошо ложится или плохо? ))
31 июл 15, 10:43    [17958876]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

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

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

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

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

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

Мне кажется, вы опять что то свое в голове держите. Ну да ладно, попробую ответить.
1) Реляционные СУБД, держат в своем ОЗУ данные которые
- используются сейчас
- использовались недавно
- используются часто
Ничего не меняется. Большой объем ОЗУпредпочтительнее, потому что СУБД будет поднята в память вся, то есть не надо будет повторно "связывать" поднимаемые записи во внутренние структуры, соответствующие объектам.
2) В обычной СУБД (под той же 1С), ежели мы запустим какую-нибудь операцию над 100 документами, СУБД все записи относящиеся к этим документам так или иначе в память поднимет, что бы передать их на сервер 1С и там выполнить операцию - вне зависимости от того, насколько сложна эта операция. В моем случае для операций типа "поставить галочку 'заблокировано'" для СУБД в её памяти нужны только те записи, которые к галочке относятся.
3) Важный фактор КМК находится с другой (инфологической) стороны. Существует гетерогенная схема, где есть обычные таблицы. По факту, объекты нужны для активной, текущей части бизнеса, где правила меняются на ходу. А всякие бух.журналы,куда всё в конце концов попадает - это традиционные таблицы. Т.е. в виде объектов в среденестатистическом масс-маркетном случае будет далека не вся БД.
31 июл 15, 11:58    [17959306]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
ViPRos
и не так как ты это пытаешься делать - переносишь программирование на сервер :) (ведь так все и сейчас делают - только на клиенте - создают класс с собственными свойствами, коллекцию (для проекций тоже) для собственных экземпляров, навигационные коллекции (проекции) связанных классов и т.д.)
т.е. модель создается на клиенте
а ты модель и переносишь на сервер, а языка такого мощного как C# допустим не можешь дать или дашь только ОДИН, а им надо много, кто на чем привык и кроме того им все равно надо делать прокси для модели на клиенте, для проекций модели и т.д.
т.е. ты просто создаешь дополнительную СЛОЖНОСТЬ :)
решение не там

Я так сложно не думаю. И я не о системщиках программистах думаю, а о прикладниках последнего звена (кто, например, с 1С общается) и о конечных пользователях. Язык, мощный как С#? Зачем это для них?

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



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

Откуда: Москва. Россия
Сообщений: 1576
ViPRos
...дополнительную СЛОЖНОСТЬ


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

Откуда:
Сообщений: 9967
[quot U-geneМне будет для начала достаточно прикрутить к этой СУБД визуальный конструктор схем, что бы он на экране таблицы и классы рисовать позволял, и визуальный конструктор интерфейсов, что бы для созданной схемы окошки и отчеты клепать.



В этой схеме[/quot]
это все ВИПРОС делает (при том не нужен никакой язык)

К сообщению приложен файл. Размер - 119Kb
31 июл 15, 13:18    [17959709]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
ViPRos
[quot U-geneМне будет для начала достаточно прикрутить к этой СУБД визуальный конструктор схем, что бы он на экране таблицы и классы рисовать позволял, и визуальный конструктор интерфейсов, что бы для созданной схемы окошки и отчеты клепать.
В этой схеме

это все ВИПРОС делает (при том не нужен никакой язык)[/quot]

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

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

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

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

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

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

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

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

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

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

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

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

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

Нами реализован принципиально иной подход к объединению объектных и реляционных свойств в рамках одной системы.
- Концепции "класс" и "объект" реализованы в соответствии с ОО парадигмой программирования и максимально похоже на распространенные ОО языки. (В ОРСУБД используются "типы, определяемые пользователем", UDT).
- Все создаваемые объекты существуют как элементы своего класса и как иначе. (В ОРСУБД экземпляры UDT хранятся в типизированных таблицах, для обработки данных в ОЗУ создаются их копии)
- Объекты уникальны. Любой объект доступен по ссылке. (В ОРСУБД, экземпляры UDT-строки уникальны и доступны в пределах таблицы, а экземпляры-атрибуты, по ссылке вообще недоступны.)
- Атрибуты объектов могут быть хранимыми и вычисляемыми (В ОРСУБД атрибуты UDT всегда хранятся как атрибуты таблицы). Это позволяет создавать гораздо более гибкие схемы данных.
- Возможно множественное наследование классов. (В ОРСУБД множественное наследовании невозможно. Наследование описывается раздельно для UDT и таблиц)
- И атрибуты, и методы классов полиморфны, их реализация может меняться при наследовании. (В ОРСУБД такой полиморфизм отсутствует).
- Возможны любые операции над группой объектов, в том числе выполнение методов (В ОРСУБД групповые операции ограничиваются операциями над типизированными таблицами)
- Переход от объектного описания объектов к реляционному представлению их данных выполняется системой неявно, незаметно для пользователя при обращении к классам. (В ОРСУБД, доступ к экземплярам UDT реализован в явных операциях доступа к типизированным таблицам, но не к самим UDT.)
Возможна операция динамической реклассификации объектов(принципиально новая опция).
Подход основан на реляционной модели данных, сохраняет ее формальные свойства (ОРСУБД значительно нарушают формальные основы РМД.)
31 июл 15, 15:33    [17960684]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
этта
Guest
U-gene

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

1. нет никакого постгри. есть "постгрес, куяль". это справка.

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

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

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

Поэтому этим и не пользуется никто.
31 июл 15, 16:34    [17961110]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
этта
Guest
U-gene,
ой, а вы всё со списанной торбочкой ООБД своей нодоноситесь.
год десятый почитай недонашиваете. бггг. узнаю брата колю

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

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

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

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

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

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

В общем, тьфу на тебя.
31 июл 15, 17:11    [17961328]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
этта
Guest
U-gene,

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


и да, я хуже ...ээ, можете не сомневаться. по меркам ...ээ.
хехе.
31 июл 15, 17:36    [17961447]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
ScareCrow
Member

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


тормозит. да и писать сложно.
1 авг 15, 18:41    [17964329]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
Зимаргл
Guest
ScareCrow
автор
Что самое забавное - по большому счету этот принцип "лОжения ООП на отношения" давным-давно используются кучей систем (тех же бизнес- систем, тем же 1С), которые собирают свои объекты из разных строк разных таблиц. Однако они таскают данные из БД, но ведь никто не мешает пойти в другую сторону - оставить данные в СУБД, а заставить её обрабатывать команды, работающие с такими объектами. Мне удивительно, это же очевидно, почему этого никто не видит?


тормозит. да и писать сложно.

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

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

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

что тормозит, не понимаю?
В обычной системе что бы обработать условную сотню объектов, клиент или апп.сервер генерит условную тыщу простых запросов (что бы достать данные их БД), СУБД их парсит, выполняя для каждого кучу работы, отдает данные по кусочку, апп.сервер обрабатывает их и другой тыщей запросов возвращает в БД. И это все в транзакции. А еще (как писал ViPRos), будучи в этой транзакции, СУБД не знает, что там будет дальше (потому что смыслы данных и логика обработки от сервера скрыты) поэтому фигакс и зависли (если рядом кто-то что-то похожее делать пытается).
Это ли не "тормозит"?
3 авг 15, 07:29    [17967515]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Зимаргл
при нормальном проектировании уже давно поставили под сомнение, что ООП всегда дает выгоду в разработке, СУБД не исключение.
У меня ООП не must, a can.
3 авг 15, 07:31    [17967516]     Ответить | Цитировать Сообщить модератору
 Re: парадигма OOP плохо ложиться на реляционные отношения...?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
да отлично ложится. Не верьте никому.
3 авг 15, 07:37    [17967518]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить