iceB-9.0

>>И сколько под него существует "бизнес-схем"

>Существенно больше чем под самописную экзотику которую вообще никто не знает. Как минимум >0.

не "существенно". Существенно -- это, по крайней мере, на порядок. А их на оффсайте существует штук 5-10.

> Все в порядке там с многопоточностью. Бровзеры тут не при чем.

ну если нормальный сервер приложений, то да. А если скриптами прикрывается отсутствие нормальной многопоточности "платформы", то повторится ситуация с Firefox. SpiderMonkey, кстати, многопоточный, но Firefox'у с XUL'ом это не помогало.

> Ага на лиспе. Если захотелось понт кинуть чтобы бедный интегратор осознал какое он дерьмо - мождно в жабу хоть окамлскриптинг вставить хоть жаскелл - или последний мой любимый хи сезона - скалу им впаять - у низ от туториалов зубы повыпадают.

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

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

>Но структуры данных внешние и

я правильно понимаю, что реорганизации структур данных не происходит и данные "плоские", не иерархические?

Допустим, добавили в "схему" новое поле. Что произойдёт со старыми данными, с новыми?

Допустим, новое поле -- типа объект, описанный в схеме выше. Допустим, объекты наследуются.

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

>Хранится все в посгресе.

есть ощущение, что версионник удобнее блокировочника тем, что интеграция с сервером приложений проще (если в сервере приложений достаточно подробная метаинформация о том, что транзакция читает/пишет, вместо giant lock'ов).

> (всякие членовредительские базы данных типа
xmlных и ял-обектных были посланы вследствии огранниченности и
тормознутости на связях и объемах)

XML-ные -- зло. Оно явно не для быстрого OLTP.
А про объектные можно поподробнее, очень интересно: что тормозит, где тормозит, на каких тестах. Как разруливается, например, переструктуризация БД в постгрессе при изменении схемы данных (ООБД это берут на себя). Насколько расширяема схема данных вообще, и какие у нее ограничения структуры (например, захотелось хранить вместо строки 'user' объект user из "справочника").

Как выполняются более хитрые запросы, например, вхождение в иерархии. Что-то вроде запросов на прологе в том примере с PicoLisp.

>А что такое тормозит? ЗАпускается не мгновенно?

тормозит -- это когда вместо четкого движка с интерфейсами рендеринга, перерисовки, DOM, UI, загрузки данных/прокси имеем размазню в виде отрисовка отдельно, DOM в RDF datasource отдельно, UI на JS в котором реализован этот API движок-DOM(RDFDataSource) отдельно, загрузка отдельно, модель событий "вызов API при изменении RDFDataSource" отдельно.

Тормозит именно RDF как универсальное метаописание, и его обработка в JS. Может, с нормальным JS движком вроде Chrome/Tamarin-tracing тормозить будет меньше.

Но заметим, что при дальнейшем расширении "плагинами на JS" все эти плагины интерпретируются и могут потенциально конфликтовать друг с другом. В итоге система из потенциально многопоточной становится кагбе кооперативно многозадачной в духе Windows 3.1, и возникает узкое место (а поскольку "плагины" подключаются в разные слои, отпрофилировать конкретный плагин и выяснить, кто из них тормозит становится сложно). Вот что я называю проблемами XUL (или логики на скриптах другого интерпретируемого движка).
Вопрос, чем ограничена масшабируемость решения с интерпретируемыми скриптами? И не лучше ли это узкое место расширить?

>Что там развесистого в сервелтах и жсп - непонятно

и правда, что там в этой жабе "развесистого"
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

>То что туториалы хелловордов занимают 5 строк не важно, важен размер libc, рантайма в static варианте.

Ага для мобильных телефонов. А не....

>а должен?

Нет. Но претензии к тому кто умеет странные.

>сильно много умеет *не нужного мне*. >Но в этом конкретном приложении с одним сервером приложений с одной СУБД -- это зачем?

Не пользуйся. Это так тяжело? Не пользоваться... В этом нет ничего страшного. Эти жарники лежащие там ничего плохого никому не делают.

>что "бред собачий"?

ТАм рписано ЕЖБ лохматое. ТАк вот - не пользуйся. Не нужно.

>Что стек Ява-технологий сам по себе слишком тяжел для простых проектов?

Именно. Жаба - язык. Что толстого в ЖДБС? Что толстого в языке? Что толстого в жаваскрипте? Аналог сервлетного и темплейтного движка есть в любом сервере - даже на пыхе подобнеым образом пишут сейчас. Где толщина? Не нужен JMX - не ешь, не надо EJB - не пользуйся. Возьми самый простой набор который нужен и пиши - ничего плохого в этом нет - из под палки в ежб никто не гонит.

>ещё 30% cpu на вот это?"

Нету никаких 30% ЦПУ.

>а не объектов предметной области.

Это писали люди. В данном предложении смешали претензии о том как они писали и что они дюля этого использовали. Жаба тут не при чем. Например ЖБосс даже свой портал ежбшным сделал. Это проблемы ЖБосса а не жабы. Не надо перекладывать проблемы в головах на проблемы технологий. Я там сверху привел реальный проект - небольшгая КИС - написл ее за фигню времени. И нету у меня исключений в гибернейтах - в основном потому что гибернейта нет. И 8 файлов там не используется для одного компонента - потому что нет там ЕЖБ.

>ну если нормальный сервер приложений, то да.

Параллельность к жаваскрипту как к языку отношения не имеет.

>ну суть в том, что функциональщину с минимумом побочных эффектов.

Надо осознавать рынок для которого система создается. Интегратор не будет нанимать лисперов для того чотбы конфигурить бухгалтерию. А лисперы не будут наниматься к интегратору чтобы конфигурить бухгалтерию. В этом суть.

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

Ну так скала в руки. Но опять же надо понимать возможности привлечения кадров к проекту. Чем хаскелистее технология тем меньше будет кадров.

>я правильно понимаю, что реорганизации структур данных не происходит и данные "плоские", не иерархические?

Иерархические. Я привл дескриптор одного обекта - там где написано reference - это ссылка на другие объекты.

>Допустим, добавили в "схему" новое поле. Что произойдёт со старыми данными, с новыми?

Все в порядке. Будут работать все. Старые остануться с пустым новые будут с новым. Все согласно задумке.

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

При таком изменении она не нужна. Написать мигратор - говно вопрос. Просто он не нужен был.

>А про объектные можно поподробнее, очень интересно: что тормозит, где тормозит, на каких тестах.

Во первых они имеют весьма специфические модели взаимодействия с ними из-за транзакций на памяти, во вторых миграция и изменение модели данных это всегда пэйн ин эсс по причине того что модель представления и хранения сильно влиеяет на модель обработки.

Но вообще если рассматривать проект яля конкурент для 1С то необходимым фактором является возможность взаимодействия сторонних систем по стандартным протоколам к которым вполне относятся SQL и стандартные вебсервисы.

>Как выполняются более хитрые запросы, например, вхождение в иерархии

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

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

> Не пользуйся. Это так тяжело? Не пользоваться... В этом нет ничего страшного.

угу, тяжело. Холостой порожняк давит на мозг одним фактом своего существования. Или это ружьё висит неспроста, и в третьем акте выстрелит, или оно не нужно вообще.

> Что толстого в ЖДБС?

то, что JDBC -- платформенная обертка поверх ODBC, которая сама обёртка над native api. Потом ещё ORM поверх JDBC, и полный зоопарк с медведями на велосипедах.

> Что толстого в языке?

язык то наоборот, искусственно урезан. Платформа да, толста. Потому что встроить другой язык в тот же Си обернётся гораздо более компактной "платформой" в итоге, чем те же JNI в жабе.

>Что толстого в жаваскрипте?

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

> Где толщина? Не нужен JMX - не ешь, не надо EJB - не пользуйся. Возьми самый простой набор который нужен и пиши - ничего плохого в этом нет - из под палки в ежб никто не гонит.

мда, как с safe C++ ABI. Всеми этими развесистыми фичами можно не пользоваться, и тогда всё будет работать ОК. Вопрос, а зачем они воопще нужны? ну то есть, бренд, платформа -- это модно и клёво, это на слуху. Правда выясняется, что половиной не нужно пользоваться, если не нужна "толщина".

> Это проблемы ЖБосса а не жабы. Не надо перекладывать проблемы в головах на проблемы технологий

+1

> И нету у меня исключений в гибернейтах - в основном потому что гибернейта нет

да, "гибернейт -- замечательная технология, если ей не пользоваться" :) великолепно. Иначе это ещё один способ выстрелить себе в ногу (например, не обновили схему гибернейта и схему БД. Получили гибернейт с констрейном NOT NULL, и БД с NULL значением. Не поправив руками БД (или схему), имеем спрятанные небольшие детские грабельки).

> Старые остануться с пустым новые будут с новым.

а надо с дефолтным из схемы. Хорошо, что гибернейта нет, а то были бы грабли

> Написать мигратор - говно вопрос. Просто он не нужен был.

а в "платформе" кис это один из ключевых вопросов удобства. Хотя непринципиальный, в том же compiere вполне справляются SQL дампами.

> модель представления и хранения сильно влиеяет на модель обработки.

MVC отменили? в ООБД удобно что некоторые ОО СУБД-"серверы" могут сам справится с реструктуризацией перемещением объекта по иерархии, изменением экземпляра объекта, и т.п. Как в примере с PicoLisp: добавили тег, удалили тег.

Впрочем да, влияет. Так в этом и смысл, найти другую модель для более удобной обработки.

> по стандартным протоколам к которым вполне относятся SQL и стандартные вебсервисы.

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

> Обычно такие базы предполагают что запросы не нужны - у вас и так дерево всосано в целевой язык в виде обектов - пишите циклы.

рефлексия, MOP, запросы по метаданным

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

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

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

странно, по идее должно быть наоборот удобнее. Тот же ORM или реестр сервисов должен быть проще

> Интегратор не будет нанимать лисперов для того чотбы конфигурить бухгалтерию. А лисперы не будут наниматься к интегратору чтобы конфигурить бухгалтерию.

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

><Или это ружьё висит неспроста, и в третьем акте выстрелит, или оно не нужно вообще.

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

>то, что JDBC -- платформенная обертка поверх ODBC, которая сама обёртка над native api. Потом ещё ORM поверх JDBC, и полный зоопарк с медведями на велосипедах.

То есть ты даже не знаешь что такое JDBC. Изучи хотя бы википедию для начала.

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

И эти люди мне мешают ковыряться в носу. ЗАчем в бухгалтерской программе вообще язык имеющий доступ к нативу - вопрос века.

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

Я знаю программу которая такие тексты ничего общего с реальностью генерить умеет.

>Вопрос, а зачем они воопще нужны?

Для тех кто знает не только хотябы что такое JDBC но и представляет что такое X/Open DTS.

>Не поправив руками БД (или схему), имеем спрятанные небольшие детские грабельки).

Ага - есть либастрал который это правит замечательно просто.

>а надо с дефолтным из схемы

Не надо. Сюрприз? Надо было бы - было бы с дефолтным.

>MVC отменили?

Для чего - для объектных баз данных?

>в ООБД удобно что некоторые ОО СУБД-"серверы" могут сам справится с реструктуризацией перемещением объекта по иерархии, изменением экземпляра объекта, и т.п.

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

>Так в этом и смысл, найти другую модель для более удобной обработки.

Например вспомнить что протаскивать данные в обектном виде в движковую часть - и нафиг не нужно.

>Поэтому нужнен какой-то слой над данными, чтобы в него просто отображалась любая модель, RDBMS, OODB (если частная модель удобнее в конкретном случае).

Я зайду через 10 лет - думаю воз будет и ныне там а 1С и ныне там где он есть.

>Один метод хранимого объекта -- одна транзакция.

ТАкие транзакции - нафиг не нужны.

>Тот же ORM или реестр сервисов должен быть проще

ORM проще в узких случаях. ОРМ не нужен хотя бы потому что не нужно писать код который работает с ормом. Стандартной практикой вон считается вытянуть обект из реляционгой базы превратить его в обект языка, и вывести его в маркап HTML.

Возникает вопрос если цель превратит запись в базе в маркамп - зачем ОРМ?

>Они могут создать платформу с более удобным DSL, на котором будут писать "интеграторы".

Еще раз - интегратор это такой чудак который этого DSLа не знает. Это 1С мог вылезти во времена когда были распространены foxpro, в банках стояли системы типа scrooge и тд - то есть подход своего мегаязыка для того чтобы и интерфесы рисовать и базу опрашивать был распространен и типичен. В современном мире очередной такой язык некто не будет учить - это будет мертворожденное дитя. РЫнок захвачен 1Сом, и очередную фигню учить никто не будет с непонятными перспективами внедрения - в топике тут очень правильно высказались про клипс. Чтобы такое продать надо будет бабла в маркетинг и раскрутску вбухать столько что можно и армию профессионалов для разработки нанять.

>Хотя осознаю что это ССЗБ с точки зрения кадров, ага.

Ну так о чем тогда говорить.

>Изучи хотя бы википедию для начала.

The Java 2 Platform, Standard Edition, version 1.4 (J2SE) includes the JDBC 3.0 API[1] together with a reference implementation JDBC-to-ODBC Bridge, enabling connections to any ODBC-accessible data source in the JVM host environment. This Bridge is native code (not Java), closed source, and only appropriate for experimental use and for situations in which no other driver is available,[2] not least because it provides only a limited subset of the JDBC 3.0 API,[3], as it was originally built and shipped with JDBC 1.0 for use with old ODBC v2.0 drivers[4] (ODBC v3.0 was released in 1996[5]).

ну другая реализация интерфейса, функционально аналогичного ODBC, не суть. Главное, велосипед аналогичный, и всё равно его прячут под ORM.

> И эти люди мне мешают ковыряться в носу.

Да ковыряйся на здоровье, лучше уж в носу.. речь не о том, что "нужен такой язык". Речь о том, что платформу можно сделать по-разному.

> Я знаю программу которая такие тексты ничего общего с реальностью генерить умеет.

parse error. Причём тут "тексты"? Берем тесты, количество транзакций в минуту. Меряем, смотрим. Открываем Firefox 2 и ниже со 150..200 вкладками, нажимаем "перегрузить все вкладки". Много думаем.

> Для тех кто знает не только хотябы что такое JDBC но и представляет что такое X/Open DTS.

я знаю карате, айкидо и много умных слов. Радуйтесь, ваш век недолог. Уйдёт туда же, куда и программирование на MFC и COM.

>>MVC отменили?

>Для чего - для объектных баз данных?

угу. Модель есть, контроллер тоже. Представление вынесено на клиент, его можно опустить.

> Ага - они телепаты - ты переименовл поле в коде а они догадались как отмирировать базу без подсказки

неа. Они просто поддерживают более динамические ОО модели, как в той же Руби/питоне/Смоллтоке. Добавили метод, удалили метод. Поменяли в истансе базовый класс, и т.п.

> РЫнок захвачен 1Сом, и очередную фигню учить никто не будет с непонятными перспективами внедрения

а почему он им захвачен? почему этот его мегаязык считается понятным и доступным (правда, несерьёзным?) Значит, задачу на нем решать удобнее, чем в чистом языке? писали бы тогда уж на COM на С++ целиком, чего уж

>ну другая реализация интерфейса, функционально аналогичного ODBC, не суть.

Ничего в нем функционально аналогичного JDBC нет. Есть 4 типа драйвера и упомянутый там RI это тип 1. Самый распространенный и функциональный драйвер это тип 4 - прямое сетевое соединение с базой.

>ткрываем Firefox 2 и ниже со 150..200 вкладками, нажимаем "перегрузить все вкладки". Много думаем.

*С подозрением* а ты на примере пожарных машин грузоподьемность гражданской авиации не провоал мерять? Я вижу тут аналогичную связь.

Это ж надо возможность многопоточности языка (что само по себе саундс лайк бред если только этот язык не специализированный а жабаскрипт не он) мерять количеством транзакций на базе да еще и не базой а вкладками бровзера с котормы 0 общего кода. О май факин год.

>я знаю карате, айкидо и много умных слов

Вот и занимайтесь своим делом а не вступайте в дискуссии если даже не знаете какого цвета учебник.

>угу. Модель есть, контроллер тоже. Представление вынесено на клиент, его можно опустить.

А еще употребляя какой либо паттерн неплохобы не скипать такой мааленький раздел именуемый обычно motivation. Который и является анамнезом для применения диагноза в виде паттерна а не "чтобы было".

>. Добавили метод, удалили метод. Поменяли в истансе базовый класс, и т.п.

Ага. И уже инстанциированные обекты резко поменялись да? Если приводить к примеру рельсы - не заметили такую хрень как миграционные скрипты? ТАки нету либтелепатия а все руки загребущие?

>а почему он им захвачен? почему этот его мегаязык считается понятным и доступным (правда, несерьёзным?)

Хрена с два. Не знаю сколько видели вы систем - но они все на одно лицо - в начале 90х это было очень модно. На практике эти свойства так и не появились нигде - только во сейчас микрософт вытянул их в С#.

> Ничего в нем функционально аналогичного JDBC нет

аналогичный слой абстракции конкретной БД. Как если делать абстракцию native api СУБД в своём ORM.

> Это ж надо возможность многопоточности языка

не языка, а приложения-платформы. Например, в Mozilla через RDFDataSource читается localstore.rdf который становится узким общим местом -- доступ из скрипта на запись к общему ресурсу, который представляет платформа является "транзакцией". Хорошо хоть пишется редко, и "транзакций" там на запись толком не возникает (особенно когда в sqlite разделили в FF3). Да, понятно, что в яве/rhino это наверняка будут synchronized методы.
Вот например в Google Chrome есть диспетчер процессов, и браузер выступает сервером приложений для отдельных вкладок-процессов. "Транзакции" можно локализовать до процессов. Ну скажем не "транзакции" а критические секции в приложении-платформе (сервере приложений).

> мерять количеством транзакций на базе да еще и не базой а вкладками бровзера с котормы 0 общего кода

серверный JS на базе, клиентский JS в браузере -- это кто предлагал? Где в этом серверном JS внутри блокировки?

> а не вступайте в дискуссии если даже не знаете какого цвета учебник

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

>> модель представления и хранения сильно влиеяет на модель обработки.

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

>. Модель есть, контроллер тоже.

>motivation. Который и является анамнезом для применения диагноза в виде паттерна а не "чтобы было".

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

>Ага. И уже инстанциированные обекты резко поменялись да?

ага. Я же про ОО СУБД говою с гибкими объектыми моделями. Она, СУБД, и отследит версии объектов и поменяет инстансы.

> Если приводить к примеру рельсы

не канает. Рельсы -- это ORM, R делает scaffolding и т.д. В ООСУБД mapping делает сама СУБД.

> Возникает вопрос если цель превратит запись в базе в маркамп - зачем ОРМ?

давай на APL будем бизнес-логику писать. Или на J, чего уж там.
ORM нужен для метаданных. "протаскивать данные в обектном виде в движковую часть" -- тоже.

>>Один метод хранимого объекта -- одна транзакция.

>ТАкие транзакции - нафиг не нужны.

один метод метакласса -- тоже транзакция.

>аналогичный слой абстракции конкретной БД.

В чем он аналогичный? Все уважающие себя люди пишут драйвер тип 4 - прямое сетевое соединение с апи базы на чистой реализации без jni. В чем тут аналогия с ODBC?

>Да, понятно, что в яве/rhino это наверняка будут synchronized методы.

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

>серверный JS на базе, клиентский JS в браузере -- это кто предлагал?

А то что отсутствие многопоточности в бровзерном жабаскрипте обусловлено исключительно бровзером - это что мелочи?

А то что реализация этого в бровзере ничего общего с реализацией для сервера не имеет - это забыли?

>Где в этом серверном JS внутри блокировки?

Нигде.

>бгг, неканонический цвет учебника может так напугать апологета явы?

Нет критика технологий в отсутсвие даже общих знаний о ней - это кого угодно может напугать - малоли на что такой человек еще способен.

>Что он не разделяет стандарта, реализации стандарта и достижения аналогичной функциональности другим способом?

ТАки какого цвета учебних посмотреть не хотим. X/Open DTP(S) - это Distributed Transaction Processing(Services). Ничего специфичного к жабе не имеет - он разрабатывался The Open Group и является спецификацией для всех кто собирается поддерживать распределенные транзакции. Для того чтобы "достигнуть аналогичной функциональности" - вам сначала придется заставить производителей майэскуэлов постгресов и прочих ораклов реализовать эту вашу аналогичную функциональность - а то они понимаешь ли глупые знают, что такое X/Open DTP. НУ а пока вы не начали убеждать вендоров баз данных написать апи под ваш аналогичный способ лучше все же перед толканием таких идей заходить в гугл.

>что мешает "модель обработки" делать через Controller, если нужно абстрагироваться от ?

Если абстрагироваться от сумысла - то конечо ничего. Абстракция от смысла и сути вещь мощная.

>не канает. Рельсы -- это ORM, R делает scaffolding и т.д. В ООСУБД mapping делает сама СУБД.

Это не отменяет необходимость для этой базы знать смысл изменений. Если программист один класс грохнул и вместо него создал два - без рукопашногол втолковывания базе что именно он сделал никаких данных база не трансформирует. А модель этого втолковывания обычна связана с основным хост языком объектов и специфична для каждой базы. А из этого проистекает большая зависимость структуры данных на внутреннюю реализацию OODB. Можно и ей слой абстракции нагородить - но тогда возникает вопрос для чего все это надо если вся обектная модель данных будет обернута в другой слой.