ООП гораздо полезнее в теории, чем на самом деле

> Кофейник.Подготовить;

Steve Yeggie в ссылке про "Kingdom of Nouns" ещё анекдотичнее написал. Про "от того, что в кузнице не было гвоздя" (или можно как пример взять "Дом, который построил Джек")

> А если ты пишешь сложный код, реализующий поведение объектов с большим количеством атрибутов, то не использовать ООП - это клиника.

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

> Почему в бизнес-программировании так развит SQL?

так исторически сложилось

> Никого факт существования SQL не раздражает и я почти никогда не слышал, чтобы кого-то тошнило от SQL.

например, на голом реляционном SQL сложно программировать иерархические данные. Громоздко выглядит в чистых таблицах без расширений.
А если данные сами по себе зависят от других данных и перевычисляются (например база знаний с ленивым вычислением) то SQL тут явно лишний.
Собственно, чего удивляться: реляционная модель универсальна, но не удобна для некоторых применений (для которых удобнее ООБД или многомерные кубы или ещё что-нибудь).
И вместо того, чтобы носиться с "универсальным решением" (шашки,домино и шахматы) лучше бы изобрести новую более подходящую для задачи модель.


>Поэтому, SQL не вызывает возражений и споров, а просто используется (с выгодой) везде, где он уместен.

"где он уместен". Так же как и ООП, не надо носиться с универсальным "Golden Hammer"

> Да, шаблон визитор или как там пишут в ваших псевдо-умных сектантских библиях. На самом деле, это - костыль.

на самом деле, большинство GoF шаблонов - это костыль. Патамучта С++.

>И заплачете.

"но будет уже поздно. Сознание уже испорчено С++, мухахахаха!"

>Это букварь, но очень многие, как и положено, \"прогуливали школу\" :)

Это устарелое пособие о том, как программиовать микропроцессоры с 8кб памяти на фортране. Современный букварь, в котором качественно излагается программирование и объектно-ориентированный дизайн дается с первых страниц, это Дейтель&Дейтель \"Java: How to program\"

>http://insidecpp.ru/art/8/ (можно там ещё и про антипаттерны почитать.

«Предпочитайте композицию наследованию.» «Стандарты программирования на C++», Герб Саттер, Андрей Александреску.

А зачем по очевидному и интуитивно понятному постулату писать целую статью? Этак можно и на тему \"Волга впадает в Каспийское море\" диссертацию наляпать

> Основа ООП расширения для С пишется на самом С за несколько часов. <..> Но сравните очередь сообщений и, к примеру, компилятор SQL-запросов. Очередь сообщений - это элемент среды времени исполнения, который прост как валенок. Любой нормальный программист на С мог бы реализовать такую очередь. Но далеко не любой программист на SQL мог бы реализовать компилятор SQL.

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

> А насчет \"Почему в бизнес-программировании так развит SQL?\" потому что колхозники которых набрали по плану индустриализации^Wинформатизации поднимать IT-отрасль, ни о чем другом кроме SQL и 1Сы понятия не имеют.

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

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

>При этом, написать такой транслятор будет очень сложно.

что именно сложно? вон ро-исчислением можно много какие трансляторы написать. Сильно не вникая в семантику (а у ORM есть метаданные-семантика, что-то потенциально можно соптимизировать)

>>бизнес-слоя >это что такое?

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

> Иметь право на существование ORM система может только в одном случае, если она транслируется на скриптовое расширение SQL, типа PL-SQL. И, соответственно, транслирует методы в SQL-скрипты, оптимизируя обращения к БД. При этом, написать такой транслятор будет очень сложно. В противном случае, потери эффективности будут катастрофичны.

смысл: ORM система может транслироваться в разные запросы, расставлять индексы. Как если SQL-запрос транслируется в разное исполнение, составляется план запроса, и выбираются потенциальные индексы. Со старыми индексами план запроса может быть один, с другими индексами -- другой, "более оптимальный". А если ещё и сами SQL-запросы могут также выбираться разные, с оптимальным отображением ORM-SQL, то... возникает вопрос, а зачем нам кузнец ^W SQL :))

> Objects Are Organic

Recycle Your Objects, Save The World! :)

> барахла "вагон и маленькая тележка", причём регулярно "приходит новый состав" либо старое барахло надо перелопачивать под новые правила.

ээ, а у вас есть универсальный слой для метаданных старого и нового барахла? чтобы не перелопачивать, а обобщить.

>кто-то другой прямо за пару дней "въедет" в развесистую структуру БД и мигом сообразит где и что надо поменять в связи с "новыми правилами"?

значит метаданных нет?

это как в том анекдоте, приманивают троллей: хиппи-хиппи-хиппи, лишп-лишп-сикп

>слой КИС, реализующий бизнес-логику. То есть, поведение объектов предметной области не в подробностях реализации, а на уровне метаданных, метаописаний и онтологий.

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

p.s. ссылки на стандарты будут? гост или международные, а то этот словоблуд читать неохота

> с хранимыми процедурами проблем нет как правило никаких

Могу показать храниую процедуру со 118 параметрами, а потом предложить ею воспользоваться, да. А еще у нее есть соседки в 98 параметров, 104 параметра и совсем детские - в 48 и 62 параметра. Такие же фанаты SQL написали.

> Ведь я могу где-то на втором десятке лет эксплуатации реализовать для руки ещё и интерфейс "дрочилка"

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

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

> Реляционный подход гораздо более гибок, чем объектный

Вы больной или лечитесь?

circle(id,diameter,center_x,center_y)

colored_circle(id,border_color) primary key(id) foreign key (id) references circle(id);

filled_circle(id,inner_color) primary key(id) foreign key (id) references colored_circle(id);

Это какой подход - реляционный или таки объектный? Или объектно-реляционный?

> и сначала разработать нормальную табличную структуру под предметную область

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

> Подправить хранимую процедурку / добавить constraint все же проще чем ковыряться в тпипчной помойке ынтерпрайзного кода.

Вчера ковырялся в системе из 3000 таблиц, 5000 триггеров и примерно 10000 кострейнтов. А сегодня - в системе из 800 таблиц, 5000 процедур и 5000 констрейнтов. Обе системы даже не помойка, а г..но.

>Могу показать храниую процедуру со 118 параметрами, а потом предложить ею воспользоваться, да. А еще у нее есть соседки в 98 параметров, 104 параметра и совсем детские - в 48 и 62 параметра.

Аргумент уровня "Сишарп отстой потому что на нем написано это выражение: [кусок кода извлекающий из строки символы '0'-'9' и сравнивающий длину результирующей строки с нулем]" или "Перл отстой потому что на нем написан однострочник"

>Такие же фанаты SQL написали.

В SQL фана нет. Он тупо работает. Все промежуточные нагромождения между клиентским междумордием и какой-то дергалкой БД запросов - это код который по сути не делает ничего и который лучше просто выкинуть, чтобы как минимум получать нормальную диагностику с информацией какой констрейнт не позволил выполнить запрос, вместо огромных стектрейсов с чем-то невнятным типа "Unexpected Exception - this should never happen!!" на днище. То есть работа в ООП стиле это набивание кучи инфраструктурного кода который по сути кроме загадочных глюков не делает *ничего*. В ущерб тому коду который делает полезную работу.

>public static void CatRest() {
>
> while(NothingToDo()) {
>
> balls.lick();
> balls.lick();
> if(master.awake()) {
> hungry = true;
> System.out.println("Meow!!!")
> }
> }
>}

Hm... One balls for all cats... very strange... Looks like useless singleton :)

>среди тех работ есть тот же Лука Карделли, который много писал про функциональщину и систему типов

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

> В SQL фана нет. Он тупо работает.

ООП-подход также просто работает.

Я строю аккуратную иерархию классов; исходя из задачи, накидываю в них свойства и методы, и потом их спокойно дергаю, не заботясь о реализации. Если у меня встает задача поменять какой-нибудь аспект реализации, например, у меня изменилась структура storage'а, поскольку заказчик захотел расширить функциональность, либо я вообще перехожу на другой сервер в качестве бакэнда (ну например заказчик хочет MSSQL или Postgres, а не Oracle или MySQL) - я просто меняю реализацию соответствующих методов, никаким образом не трогая логику работы с самими объектами.

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

> вместо огромных стектрейсов с чем-то невнятным типа "Unexpected Exception - this should never happen!!"

Да, а сообщение constraint sys_c0003451 violated ну прямо очень понятно...

>читал

А AOCP Кнута это "букварь ассемблера", да? Может перестанешь упрямствовать и признаешь, что глупость ляпнул?

Похоже, тема начала дробиться. no-dashi, касаемо Вашего примера с окружностями. Вы как раз привели пример в доказательство того, что реляционная парадигма более гибкая, чем объектная - наследование в ней выражается без проблем. Более того одно и то же наследование можно реализовать по разному, используя представления (view). Например, "насыщенная" реализация:

create table all_circle (id,diameter,x,y,border_color,inner_color)

create view circle as select id,diameter,x,y from all_circle

create view colored_circle as select id,diameter,x,y,border_color from all_circle и т.п.

Просто самого термина "наследование" в реляционной парадигме нет. Ну и что? Дело ведь не в словах, а в сути.

Т.е., в SQL есть уже всё, что надо. И ничего сверх того.

Кто-то писал про генерацию запросов. Лучший генератор запросов - это пальцы. Конечно, неплохо бы использовать макропроцессор для генерации часто повторяющихся join-ов - представления для этой цели не очень подходят. Т.е., если прикрутить к SQL макропроцессор, то вообще жизнь прекрасна. И такие варианты в природе есть, например, spm.

> "Нормальная табличная структура" как правило получается после того, как вы выделили в системе классы (которые практически однозначно переходят в таблицы) и их атрибуты (превращающиеся в столбцы), и развертки связей много-ко-многим в отдельные таблицы

Это всего лишь Ваше желание назвать вещи теми именами, которые Вам нравятся. Сами вещи от этого не меняются. В проектировании БД это вообще-то называется приведением к 3 нормальной форме (если ничего не путаю).

Касаемо 1C - я не знаю, зачем они придумали свой SQL. И этого SQL я не видел. Возможно, оттого, что у них есть версии на локальных СУБД и на серверных - для совместимости прикладного кода тут по-любому без какого-то слоя не обойтись. Кроме того, у них есть сервисы репликации и архивирования, которые делают гораздо больше, чем родная репликация на sql-серверах. Это - ещё одна причина делать слой. А если уж такой слой делать, то ничего лучше SQL не придумать. В целом, доку по 1C я проглядывал и на вид мне понравилось - мне кажется, что это средство, адекватное задачам, для которых оно создано.

> > В SQL фана нет. Он тупо работает... ООП-подход также просто работает. Я строю аккуратную иерархию классов;

Обратите внимание, что в случае SQL работает сервер, а в случае ООП - работаете Вы. Мне всегда казалось, что машины созданы для того, чтобы работать вместо человека.

> Да, а сообщение constraint sys_c0003451 violated ну прямо очень понятно...

Оно уж явно понятнее, чем segmentation fault. Кто Вам запрещает давать констрейнтам осмысленные имена? Или хотя бы замапить констрейнты на осмысленные имена на клиентской стороне? Или тупо написать доку, где констрейнты расшифрованы?

Оракл пытался внедрить ООП ещё 10 лет назад. Они сказали: Pl-sql умрёт, будет Ява и объекты. Через пару лет они похоронили эту идею, а pl-sql, насколько я знаю, до сих пор жив. Хотя я давно не в курсе, может быть, с тех пор что-то изменилось.

> Не вижу постановки задачи, одна филология seiken, извините, нет ресурса Вас сейчас ответить. В целом, я говорил о проблеме множественного наследования, а также о выборе между абстрактными классами и интерфейсами. Все эти пробелмы, конечно же, существуют только в рамках конкретных языков, а даже не в ООП как таковом. Но в реальности приходится сталкиваться не с идеалом ООП, а с конкретными убогими языками, убого реализующими это ООП. Что и показал no-dashi своим образом мышления, привязанным к этим языкам.

> Почему? Фактически "модульная генерация" сложных SQL-запросов - не так уж и плохо

Да, не так уж и плохо, но я не уверен, что можно сделать это настолько задёшево, что уйдёшь в плюс. Может быть, выписать n inner join-ов будет в итоге дешевле. Во всяком случае, я пробовал и не получилось (может быть, не проявил должной настойчивости). Но есть проблемы. Например, обязательные/необязательные отношения и, соответственно, inner join или left join? В SQL это ясно и прозрачно, а в ООП как?

> например, на голом реляционном SQL сложно программировать иерархические данные. Громоздко выглядит в чистых таблицах без расширений. А если данные сами по себе зависят от других данных и перевычисляются (например база знаний с ленивым вычислением) то SQL тут явно лишний. Собственно, чего удивляться: реляционная модель универсальна, но не удобна для некоторых применений (для которых удобнее ООБД или многомерные кубы или ещё что-нибудь).

В целом я согласен, но только нужно уточнить, что область применения SQL очень широка. Даже и иерархические данные тоже можно освоить. И ленивые вычисления тоже можно реализовать (хотя это сильно зависит от конкретики).

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

Потому что такова природа вещей. Минимальное ООП расширение для Scheme было где-то на 4 кб. Минимальное ООП расширение для С я сам написал по ходу дела, отвечая на какое-то письмо. А вот минимальный реляционный сервер, который я видел, был то ли 50, то ли 100 кб. Живёт где-то в CPAN. Я с ним не работал и не знаю его функционал. Но вот более-менее полновесный реляционный сервер ap5 на лиспе (in-process, однопользовательский), который я пытался развивать, весит 1.5Мб в исходниках. БыдлоООП сравнивать с велосипедом - это всё же оскорбление для велосипеда, но если сравнивать, то тогда любой SQL сервер тянет не меньше, чем на автомобиль. А то и на самолёт.

На сегодня всё. Скучно будет без вас, но нужно работать.

> Дело ведь не в словах, а в сути.

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

>> В SQL фана нет. Он тупо работает.

>ООП-подход также просто работает.

Нет, не работает. За всеми этими for-лупами совершенно не видно чего автор хотел добиться. В SQL все описано декларативно: мне нужен рекордсет с данными отвечающими таким-то требованиям.

>Если у меня встает задача поменять какой-нибудь аспект реализации, например, у меня изменилась структура storage'а, поскольку заказчик захотел расширить функциональность, либо я вообще перехожу на другой сервер в качестве бакэнда

Не получится - в блокировочниках и версионниках структуры данных надо проектированить по разному. Это более чем вероятно потребует поменять API для доступа к данным из императивного кода в критических местах - например сменить синхронный API на асинхронный. BTW, почему бы не использовать OLAP & DataMining & etc цацки из оракела например? Это может дать на порядки большие бонусы чем идиотская перспектива миграции куда-то.

> Так если дело в сути, то получается, что успех SQL - это и успех и объектно-ориентированной парадигмы также, поскольку многие успешные реляционные базы по своей сути объектны. Даже наследование реализуется, как вы заметили. Отношение многие ко многим тоже. Тогда с чем спорим? ;)

Как говорят медики с биологами, у человека очень много "общего" со свиньёй. Да и в простонародье часто "пересекают" эти два понятия ;) Вот только... Ну вы поняли, да?

Здесь другой случай. Даже без ORM реляционную базу можно рассматривать как объектную модель. Частный случай. Все остается в рамках ООП.

Просто глупо сводить ООП к конкретным реализациям таким как C++ или Java. Он глубже этих частностей. Ведь речь шла о сути :)

> Касаемо 1C - я не знаю, зачем они придумали свой SQL. И этого SQL я не видел.

потому что захотелось конструкций вроде проверки на вхождение в справочник с учётом иерархии групп справочника, или итоги по регистру, или запросы писать в терминах Справочник.ХХХ , Документ.YYY а не таблиц SQL.
Притом, эффективность этого "SQL" под большим сомнением. Засекаем время выполнения объекта "Запрос", потом переписываем запрос на нормальный SQL ( или если лень ручками, берём макропроцессор как в том же 1C++). Разница во времени выполнения -- на порядок или больше.

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

основная разница в том что есть 2 представления, "объектное" в духе Visual Basic и SQL. И слой транслирует туда-сюда.
При этом императивный код благодаря SQL и слою трансляции над ним становится наполовину декларативным.

> Даже и иерархические данные тоже можно освоить.

да в курсе. Деревья хранить с счетчиком узлов лево-право, тот же Joe Celko. Плюс есть "универсальная модель данных" (УМД) поверх SQL http://www.citforum.ru/database/articles/udm/ где метаданные и онтологии записываются в таблицы.

Но если по ходу дела надо структуру (метаданные) переорганизовывать, SQL для этого неудобен. Гораздо удобнее подход вроде "демона отношений" http://www.software-lab.de/tut.html#db http://www.software-lab.de/dbui.html .
При этом код "структуры метаданных" заодно является и исполняемой моделью, метамоделью. Которую проще изменять, чем "доставать те же метаданные из УМД".

> И ленивые вычисления тоже можно реализовать (хотя это сильно зависит от конкретики).

в примерах к Practical Common Lisp простой "компилятор SQL" пишется очень просто. Правда, возникают вопросы про его полноценность, а не просто похожесть синтаксиса DSL: индексы, домены, ограничения, триггеры. Но и тут думается что у ленивости есть некоторое преимущество перед классическим SQL.

> А вот минимальный реляционный сервер, который я видел, был то ли 50, то ли 100 кб.

а нереляционные есть и на 80 Кб http://offline.computerra.ru/2001/401/10732/

> Но вот более-менее полновесный реляционный сервер ap5 на лиспе (in-process, однопользовательский), который я пытался развивать, весит 1.5Мб в исходниках.

на 1 Мб исходников тянут и ОО СУБД вроде GOODS/FastDB/GigaBASE http://www.garret.ru/~knizhnik/compare.html

ap5 насколько я понял функционально аналогичен "relation daemon" в PicoLisp, с наворотами. При этом PicoLisp явно менье исходников того же ap5, и это -- полноценный сервер приложений (правда, интерпретатор).

> БыдлоООП сравнивать с велосипедом - это всё же оскорбление для велосипеда, но если сравнивать, то тогда любой SQL сервер тянет не меньше, чем на автомобиль

ваши автомобили большую часть времени стоят в пробках. А велосипед -- едет и едет :)

> Даже без ORM реляционную базу можно рассматривать как объектную модель. Частный случай. Все остается в рамках ООП.

ну да, только вместо локально близких подобъектов в объектах имеем inner join'ы. И вместо быстрой загрузки объекта и связанных с ним http://www.garret.ru/~knizhnik/goods/readme.htm#sendobject имеем join просто для доступа к подобъекту, плюс сам запрос с подзапросами для агрегированных данных http://www.fastdb.org/fastdb_gigabase_faq.html

Первый запрос не нужен в ООБД за счёт локальности объекта и подобъекта, второй сильно упрощается.

А потом давайте попробуем реализовать MOP на SQL. будет каша из inner join'ов.

>Потому что такова природа вещей. Минимальное ООП расширение для Scheme было где-то на 4 кб <..>Но вот более-менее полновесный реляционный сервер ap5 на лиспе (in-process, однопользовательский), который я пытался развивать, весит 1.5Мб в исходниках.

сложность системы в целом примерно постоянна и не меняется в зависимости от реализации. Если SQL "слой" реализовать относительно просто, значит код, основывающийся на этом SQL слое реализовать относительно тяжело. А если POS слой ООБД реализовать относительно сложно, значит ОО код на базе него будет проще.

Речь не идет об ООБД. Речь идет о широкой трактовке самого термина ООП. Объекты, уникальность, инкапсуляция и прочее...

Кстати о птичках. Неслучайно OQL похож на SQL. Ох, неслучайно. В общем посыл состоит в том, что в RDBMS очень много объектного. Потому успехи RDBMS - это отчасти и успехи ООП. Забавный каламбур вышел :)

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

> Речь идет о широкой трактовке самого термина ООП. Объекты, уникальность, инкапсуляция и прочее...

ок, поговорим в этих терминах. У объектов есть локальность, эти данные хранятся вместе и сразу доступны при извлечении объекта из POS(ООБД). SQL с inner join'ами для эмуляции наследования и полиморфизма -- это как реализация динамической типизации вручную или посылкой сообщений. Понадобится хитрый составной индекс-ФЗ, для динамического множественного наследования -- и или запрос будет неэфективный, или объём/количество индексов будет расти нелинейно.

> В общем посыл состоит в том, что в RDBMS очень много объектного.

только RDBMS явно требует атомарности данных, и для DRY-принципа, нормальные формы (+выбор, или красиво с нормальными формами, но кучей join'ов, или некрасиво с ненормализованными таблицами и триггерами). А в ООБД наоборот данные -- самодостаточные объекты агрегатных типов, и эта агрегация вкупе с локальностью свойств объекта достаётся практически "нахаляву".

Тут прикол в другом. Наш уважаемый коллега den73 провел параллель "смотрите какой успешный SQL, вот если бы и ООП был таким уже успешным". Утрирую конечно, но основная мысль была такова. А потом на несколько портянных постов шло развитие этой темы. Мне же кажется, что такая постановка вопроса несколько забавна, особенно в свете сопоставления OQL vs. SQL... :-)

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

критика ООП http://www.geocities.com/tablizer/oopbad.htm
Lua/SQLщики отакуют http://www.geocities.com/tablizer/top.htm

Да, разговор в чём-то стал, пожалуй, выше моего уровня, и выше моих возможностей читать столько ссылок.

> основная разница в том что есть 2 представления, "объектное" в духе Visual Basic и SQL. И слой транслирует туда-сюда. При этом императивный код благодаря SQL и слою трансляции над ним становится наполовину декларативным.

Что ж, я рад за фирму 1С, они оказались на том уровне, который я ожидал. Касаемо же замедления запросов при наворачивании лишнего слоя, это - вполне ожидаемый результат и тут сложно их ругать.

> ваши автомобили большую часть времени стоят в пробках. А велосипед -- едет и едет :)

Ну я вообще-то сам сторонник велосипедов...

> У объектов есть локальность, эти данные хранятся вместе и сразу доступны при извлечении объекта из POS(ООБД).

Но нам далеко не всегда нужен весь объект. Не всегда нужно

select * from client where id=100

как правило, нужно лишь что-то типа

select name, account_number from client where id=100

разница в эффективности существенна. Когда мы захотим эффективности, это повлияет на построение системы типов для ООБД. В SQL эта проблема тоже имеет место, но ввиду отсутствия атомарности объектов, она сразу оказывается существенно легче. И ей уже давно придумано решение - представления, в т.ч. модифицируемые, к-рые в принципе позволяют поменять физическую структуру БД, не меняя прикладной код. А в ООБД такая возможность есть?

Далее, реляционный подход гарантирует исполнимость всех возможных в языке запросов по любым полям. А может ли так ООБД?

> Речь не идет об ООБД. Речь идет о широкой трактовке самого термина ООП. Объекты, уникальность, инкапсуляция и прочее...

Ага. Мультиметоды и прочее... Вот no-dashi приводит примеры ограниченного понимания ООП в связи с конкретными ущербными языками. Теперь он куда-то делся, а Вы говорите о другом понимании.

> Наш уважаемый коллега den73 провел параллель "смотрите какой успешный SQL, вот если бы и ООП был таким уже успешным".

Я не сравнивал SQL и OQL, РСУБД и ООБД. Я сравнивал (пусть это может показаться нелепым), ООП в С++ и Java с реляционными БД. Речь шла о сравнении их как социальных явлений и как инструментов для создания программ. SQL "тупо работает" и позволяет достигать успеха, а вокруг ООП почему-то идут жестокие баталии, создаются новые среды, языки, методики проектирования, пишутся книги, а работать с ним как было неудобно, так и осталось.

> Касаемо же замедления запросов при наворачивании лишнего слоя, это - вполне ожидаемый результат и тут сложно их ругать.

если только разные слои не являются равноправными представлениями одной сущности, как в Cache реляционное, объектное и многомерное представление.

> Но нам далеко не всегда нужен весь объект.

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

> к-рые в принципе позволяют поменять физическую структуру БД, не меняя прикладной код. А в ООБД такая возможность есть?

вопрос, что понимать под "физической структурой ООБД".

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

2. если в ООБД реализована гибкая система типов и что-то вроде MOP, то возможно работать через него. Например, GOODS -- активно использует аспекты для реализации чего-то вроде MOP.
Например, в Смоллтоке есть doesNotUnderstand сообщение, а в Objective C -- шаблоны "Pose As","Proxy" когда экземпляр объекта одного типа для объекта другого типа выдаёт себя за третий тип. Например, через Proxy реализованы distributed objects, а "Pose As" позволяет перекрыть в экземпляре унаследованные методы своей реализацией или выглядеть как тип другого класса, см. категории в Objective C (аналог интерфейсов, но с меньшей гранулярностью, более похоже на аспекты).
То есть, это более похоже на те "составные классы" в PicoLisp.

> Далее, реляционный подход гарантирует исполнимость всех возможных в языке запросов по любым полям. А может ли так ООБД?

"..по любым полям" -- включая private/protected?

Идея в том, что методами объекта можно реализовать конкретные нужные в контексте именно этого объекта запросы, которые и оптимизировать в первую очередь, а не все возможные в природе (из разных иерархий итп). Сервер ООБД должен только кешировать выдаваемые объекты, параметры запроса, и т.п.
"Все возможные запросы по любым полям" -- это что? Рефлексия/интроспекция/MOP для перебора полей объектов или что-то вроде OQL?
Если запрос -- это лениво вычисляемый метод, который выдаёт очередной скешированный набор объектов, то можно реализовать свой язык запросов, более удобный в контексте предметной области.
"исполнимость" -- То есть, вопрос, что гарантирует что такой запрос выдающий список объектов не "зациклится", а завершится за конечное время?

Day-off mode on:

Лично я представляю ООП как способ локализации побочных эффектов. Некое необходимое зло: тот или иной метод срет исключительно в рамках конкретного объекта. Хотя, конечно попробуй локализуй в императивном строгом языке побочные эффекты... Задолбаешься.

Да еще представление в мейнстрим языках в виде модели основанной на событиях. В CLOS, например, это сделано на основе "обобщенных функций", но лисп он декларативный. И в императивных языках такой подход принес больше минусов, чем плюсов.

ООП принесло в императивне языки более гибкое управление потоком операций (полиморфизм, инкапсуляция, перегрузка, наследование). А до этого ничего кроме тупой маршрутизации по предикату не было.

Но и проблемы такой подход принес: на мой взгляд самая главная из них - "тройственность" класса. Класс можно рассматривать класс-как-тип, класс-как-интерфейс и класс-как-поведение. И получается как в известной басне Крылова про лебедя, рака и щуку.

В декларативных функциональных, тем более в ленивых языках все несколько по-другому: там управление не потоком императивных операций, а тем что и как вычислять. Обычно делается с помощью цепочки комбинаторов, которые хитрым образом "склеивают" куски программы между собой, позволяя например, выполнять определенные действия между "шагами" вычисления. Ну и типы там - типы т.е. несут в себе тИповую сигнатуру и определяют порядок вычисления соответствующего выражения, а допустим в хаскеле, можно описывать интерфейсы, причем достаточно либерально по отношению к их дальнейщим реализациям. А вопрос "поведения" не стоит так остро, ибо проргаммисты не злоупотребляют иерархиями классов.

Это все я к чему: для императивных языков что-то кроме ООП'а придумать невозможно. А в декларативных язках императивные идиомы превращаются в антиидиомы.

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

> в ООБД тоже есть разногласия относительно того, какую часть агрегатного объекта в какой момент доставать.

Я не буду ругать ООБД так же, как мейнстримовые языки С++ - не работал с ними. Но ИМХО здесь люди (в типичной для ООП манере) создали проблемы там, где их не было. В SQL можно вытянуть с сервера ровно то, что надо, и есть способ явно и легко указать, что надо, а что - не надо. То есть, такой проблемы вообще нет. Поэтому мужественные попытки в рамках ООБД преодолеть искусственно созданные идеологией трудности лишь в самом лучшем случае позволят догнать SQL за счёт усложения прикладного программирования. А SQL всё это умел ещё в год моего рождения, когда Oracle помещался на одной дискете...

> во многих ООБД реализована работа с "версиями" объекта -- один клиент может иметь одну версию, другой другую, сервер третью

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

> если в ООБД реализована гибкая система типов и что-то вроде MOP, то возможно работать через него. Метаданные ортогональны ООП.

> "..по любым полям" -- включая private/protected? private-protected - ещё одно сомнительное изобретение Страуструпа. Потом ему понадобились френды, но и они не затыкают дыру полностью. В SQL есть механизм grant и view, позволяющий (иногда легко, иногда с гемором) создать гораздо более гибкую систему доступа, чем достижимую с помощью private/protected. Тогда - по любым полям, к которым есть права доступа (на самом деле я немножко приукрашиваю и есть ещё ограничения, связанные с семантическими неоднозначностями).

> Идея в том, что методами объекта можно реализовать конкретные нужные в контексте именно этого объекта запросы, которые и оптимизировать в первую очередь, а не все возможные в природе (из разных иерархий итп).

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

> ООП принесло в императивне языки более гибкое управление потоком операций (полиморфизм, инкапсуляция, перегрузка, наследование).

Я не верю, что люди, создавшие до возникновения ООП такие вещи, как Postgres, Автокад и Unix, были тупы.

Полиморфизм может быть и без классов. Для этого достаточно уметь хоть что-то сказать о типе данных в динамике. Полиморфные вызовы реализуются с помощью полей типа и/или таблиц виртуальных методов, в зависимости от задачи. Зазомбированным сектантам трудно это представить себе, но для этого можно использовать обычные указатели на функции. Кроме того, если сделать не одномерный вектор, а n-мерный массив указателей, то получаются мультиметоды. Их спокойно можно сделать даже в С.

Инкапсуляция - это отчасти сахар, отчасти - вопрос дисциплины. Если руки кривые, то дисциплина не поможет. Если руки нормальные, но связаны, то это тоже не продуктивно. Кроме private/protected, есть и другие способы защиты, например, с этим неплохо справляются обычные заголовочные файлы в С, а в Pascal для этого есть interface/implementation, и т.п. Для более сложных случаев пригодится МП. Впрочем, я не против инкапсуляции. Как сахар она очень ценна. Хотя вот в Паскале есть уникальная конструкция with, которая ещё намного лучше.

Перегрузка операций - это синтаксический сахар С++, не имеет вообще никакого отношения к ООП. Лучше бы они макропроцессор по-нормальному переписали, а то позорище страшное. BASIC и то в сто раз круче, чем препроцессор в С++. Потому что в бейсике есть рекурсия, а в cpp - нет. Т.е., это вообще полное говно, а не инструмент.

Наследование. Ну вот может быть оно и останется от ООП, если его раздеть. Но и его можно выразить через агрегирование.В том числе в таких языках, как SQL.

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

> Здесь другой случай. Даже без ORM реляционную базу можно рассматривать как объектную модель. Частный случай. Все остается в рамках ООП.

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

> А потом давайте попробуем реализовать MOP на SQL. будет каша из inner join'ов.

А теперь напишите на MOP эквивалент запроса с несколькими UNION-ами, в каждом с пачкой join-ов, с кучей условий, с отбором определённого количества записей и прочими "вкусностями", предоставляемыми SQL.

Может не надо натягивать "кое-что на глобус"?

>Просто глупо сводить ООП к конкретным реализациям таким как C++ или Java. Он глубже этих частностей. Ведь речь шла о сути :)

=)

Просто глупо сводить реляционную модель к ОО парадигме. Она глубже этих частностей. :)

> В SQL можно вытянуть с сервера ровно то, что надо, и есть способ явно и легко указать, что надо, а что - не надо.

хорошо, надо не "явно" указать что вытянуть, а наоборот, неявно задать отношения и признаки. Язык запросов SQL не расширяем, и придётся городить какой-то макропроцессор, отображать этот язык в SQL. А зачем S-QL, когда можно сразу другой xQL?

> Поэтому мужественные попытки в рамках ООБД преодолеть искусственно созданные идеологией трудности лишь в самом лучшем случае позволят догнать SQL за счёт усложения прикладного программирования.

прикладное программирование как раз упрощается, ибо программируется в естественных для предметной области терминах. Вот в системном программировании ООБД сервера всё не так просто, но оно с прикладной стороны сильно и не видно.

> Т.е., там, где в ООП надо писать море вложенных циклов, в SQL надо писать вместо них Join-ы, а план выполнения строится сервером автоматически и может меняться в зависимости от набора индексов.

а что мешает в ООП реализовать декларативный язык запросов? Который вместо "универсальной" реляционной модели с join'ами будет работать в терминах множеств объектов предметной области, отфильтрованых по более гибкому набору отношений: порядка, иерархии, агрегирования, метаданных?

> Т.е., один и тот же декларативный запрос может означать на деле совершенно разные форматы хранения и способы извлечения данных. В случае ООП для этого потребуется рефакторинг, в случае SQL - всего лишь переделать индексы.

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

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

> Т.е., ООП распадается на несколько независимых идей, каждая из которых (и все вместе) отдельно легко реализуются.

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

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

> Может не надо натягивать "кое-что на глобус"?

написать-то можно. Вопрос, чтобы написать достаточно расширяемым способом.

> BTW, почему бы не использовать OLAP & DataMining & etc цацки из оракела например?

А у меня не OLAP-задача, а OLTP, с большим количеством алгоритмически не особо сложных операций. А вопрос потенциальной миграции как раз стоит очень и очень насущно.