Про ORM

>> То есть не потому что иерархическая модель никуда не годилась, а потому что реляционная модель была много лучше.

>Она не лучше, она банально быстрее. Точнее, позволяет создавать быстродействующие СУБД.

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

>> Чем лучше ОО модель мне абсолютно не понятно.

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

низкоуровневость не мешает принципиально. Например, MUMPS низкоуровневый и императивный, что не мешает на нём реализовать и SQL и ООБД и любую другую произвольную модель данных (как не мешает низкоуровневость Си реализовать произвольный ОО вроде GObject). Вот непрозрачность, да мешает (как единственно возможный поддерживаемый статический ОО в том же С++).

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

> И хранятся вместе с данными? 8)

Вообще говоря, why not? как часть метаданных. а-ля хранимые процедуры.

>> И хранятся вместе с данными? 8)

> Вообще говоря, why not?

Я и спрашиваю, как на сегодняшний день обстоят дела.

> а-ля хранимые процедуры.

Если их можно расширять только встроенным языком СУБД, это не интересно. Если не только - то чем? Там внутри .NET VM? JVM? Еще что-нибудь?

> Пихать новые типы в БД конечно можно, но это ничего принципиально нового от типа integer в себе не несёт.

целостность, атомарность абстракных типов данных (два integer в разных столбцах связаны). Более компактные транзакции-методы.

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

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

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

http://en.wikipedia.org/wiki/Worse_is_better#The_MIT_approach

http://www.dreamsongs.com/WIB.html с пункта 2.1

> как и с тем, что с небольшим объёмом данных просто файловой системы более чем достаточно.

или с большим объёмом, но с тривиальными не меняющимися запросами

> Если их можно расширять только встроенным языком СУБД, это не интересно. Если не только - то чем? Там внутри .NET VM? JVM? Еще что-нибудь?

зависит от реализации конкретной ООСУБД. FFI много кто поддерживает.

>> Если их можно расширять только встроенным языком СУБД, это не интересно. Если не только - то чем? Там внутри .NET VM? JVM? Еще что-нибудь?

> зависит от реализации конкретной ООСУБД. FFI много кто поддерживает.

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

на FFI пишутся методы в серверной части, клиент тупо вызывает методы объектов, исполняющихся на сервере. "встроенный язык СУБД" как правило задаёт модель данных, логика(методы) могут писаться или "на самом языке СУБД" (в том же Cache') или сразу на том языке, каком надо (JVM, .NET, FFI).

> на FFI пишутся методы в серверной части, клиент тупо вызывает методы объектов, исполняющихся на сервере.

С серверной частью всё ясно. Вопросы начинаются тогда, когда объект отправляется к клиенту на другую машину, и клиент пытается вызвать метод.

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

Грамотное применение МОР и своя реализация кеширования позволяет не гонять объекты туда-сюда без надобности.
Как-то так.

> http://en.wikipedia.org/wiki/Worse_is_better#The_MIT_approach

Не о том. Объектный подход гораздо сложнее реляционного, просто некоторые частные случаи затачиваются под объектный подход, а потом раздувают их на всю вселенную.

>> как и с тем, что с небольшим объёмом данных просто файловой системы более чем достаточно.

>или с большим объёмом, но с тривиальными не меняющимися запросами

Поиск ближайшего числа к заданному тривиальный запрос? Ну тогда файловая система без индексов проседать будет.

Completeness the design must cover as many important situations as is practical. All reasonably expected cases must be covered.

>> Simplicity is not allowed to overly reduce completeness.

Simplicity the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

> Объектный подход гораздо сложнее реляционного,

но интерфейс проще. Более высокоуровневый (хотя это "вырожденный частный случай", ага)

И интерфейс сплошь и рядом оказывается не проще. ОО - это способ скрыть ошибки от взора реальных пользователей.