Здравствуйте, GlebZ, Вы писали:

GZ> Проблема в DLink. Чтобы остаться на рынке, нужно быть лучше чем оный. Вопрос только в чем.
Тут на днях Clemens Vasters выступил (довольно известный архитектор, недавно в MS перешел), наехал он на OR-мапперы непадецки, а когда его спросили, "а как же DLinq", он ответил следующее:

Now you can (and some already have) ask how all of that plays with LINQ and, in particular, DLINQ. Mind that I don't work in the LINQ team, but I think to be observing a subtle but important difference between LINQ and O/R*:

• O/R is object->relational mapping.
  
• LINQ is relational->object mapping.

LINQ acknowledges the relational nature of the vast majority of data, while O/R attempts to deny it. LINQ speaks about entities, relations and queries and maps result-sets into the realm of objects, even cooking up classes on the fly if it needs to. It's bottom up and the data (from whatever source) is king. Objects and classes are just tooling. For O/R mapping, the database is just tooling.

Здравствуйте, Merle, Вы писали:

GZ>> Проблема в DLink. Чтобы остаться на рынке, нужно быть лучше чем оный. Вопрос только в чем.
M>Тут на днях Clemens Vasters выступил (довольно известный архитектор, недавно в MS перешел), наехал он на OR-мапперы непадецки, а когда его спросили, "а как же DLinq", он ответил следующее:
M>

M>Now you can (and some already have) ask how all of that plays with LINQ and, in particular, DLINQ. Mind that I don't work in the LINQ team, but I think to be observing a subtle but important difference between LINQ and O/R*:
M>

M>
• O/R is object->relational mapping.
  M>
• LINQ is relational->object mapping.
  M>

M>LINQ acknowledges the relational nature of the vast majority of data, while O/R attempts to deny it. LINQ speaks about entities, relations and queries and maps result-sets into the realm of objects, even cooking up classes on the fly if it needs to. It's bottom up and the data (from whatever source) is king. Objects and classes are just tooling. For O/R mapping, the database is just tooling.

Маркетинг чистой воды. DLinq — нормальный ORMapper. В вопросах трансформации из физ. реляционной модели в логическую объектную каждый уважающий себя ORM выпендривается. Они выпендрились именно так. Трансформация объектов вплоть до операции проекции(что пожалуй нужно только для отчетов). На выходе все равно есть коллекция объектов. И при этом типизированных объектов(не важно, явно типизированных или неявно). DLink вполне самодостаточный ORM.

Здравствуйте, Merle, Вы писали:

M>Тут на днях Clemens Vasters выступил (довольно известный архитектор, недавно в MS перешел), наехал он на OR-мапперы непадецки, а когда его спросили, "а как же DLinq", он ответил следующее:

Грамотный мужик, поддерживаю на 100%. Каждая часть приложения должна заниматься тем, что она умеет делать лучше всего.

Здравствуйте, GlebZ, Вы писали:

M>>LINQ acknowledges the relational nature of the vast majority of data, while O/R attempts to deny it. LINQ speaks about entities, relations and queries and maps result-sets into the realm of objects, even cooking up classes on the fly if it needs to. It's bottom up and the data (from whatever source) is king. Objects and classes are just tooling. For O/R mapping, the database is just tooling.

GZ>Маркетинг чистой воды. DLinq — нормальный ORMapper. В вопросах трансформации из физ. реляционной модели в логическую объектную каждый уважающий себя ORM выпендривается. Они выпендрились именно так. Трансформация объектов вплоть до операции проекции(что пожалуй нужно только для отчетов). На выходе все равно есть коллекция объектов. И при этом типизированных объектов(не важно, явно типизированных или неявно). DLink вполне самодостаточный ORM.

Главное я выделил.

Здравствуйте, IT, Вы писали:

IT>Главное я выделил.
LINQ и DLINQ — похожие вещи но с разными целями. Я вообще плохо понимаю зачем нужен LINQ. Только разве что для организации локального хранилища объектов. Я очень сомневаюсь что кому-то надо трансформить логическую модель. Сейчас разговор о DLinq. А он как раз и есть ORM.

Здравствуйте, GlebZ, Вы писали:

GZ>LINQ и DLINQ — похожие вещи но с разными целями. Я вообще плохо понимаю зачем нужен LINQ. Только разве что для организации локального хранилища объектов. Я очень сомневаюсь что кому-то надо трансформить логическую модель. Сейчас разговор о DLinq. А он как раз и есть ORM.

Принципиальное различие в том, что ORM скрывает от разработчика детали работы с БД. Точнее пытается скрыть, но делает это не всегда хорошо. Лично мне, как разработчику, понимающему что такое БД, этого, спасибо, не надо. Я даже считаю это вредным. Я хочу чтобы мне помогали, а не думали за меня. Если мне нужен сложный запрос к БД, то я хочу быть на 100% уверен в том, что он максимально эффективен и отлажен, я хочу посмотреть план и убедиться, что лишних ресурсов этот запрос не потребляет. Никакому ORM в этом случае я доверять не могу. Точнее скажем так. Я недостаточно уверен в том, что способен нарисовать такую объектную модель, которую подхватить ORM и эффективно отобразит её на реляционную структуру.

А маппинг — это дело десятое, это вообще перекладывание из пустого в порожнее. BLToolkit умеет перекладывать что попало во что угодно. БД лишь частный случай. В этом принципиальное отличие от ORM.

Здравствуйте, IT, Вы писали:

IT>Принципиальное различие в том, что ORM скрывает от разработчика детали работы с БД. Точнее пытается скрыть, но делает это не всегда хорошо. Лично мне, как разработчику, понимающему что такое БД, этого, спасибо, не надо. Я даже считаю это вредным. Я хочу чтобы мне помогали, а не думали за меня. Если мне нужен сложный запрос к БД, то я хочу быть на 100% уверен в том, что он максимально эффективен и отлажен, я хочу посмотреть план и убедиться, что лишних ресурсов этот запрос не потребляет. Никакому ORM в этом случае я доверять не могу. Точнее скажем так. Я недостаточно уверен в том, что способен нарисовать такую объектную модель, которую подхватить ORM и эффективно отобразит её на реляционную структуру.
Собственно поэтому ORM кроме объектного языка запросов поддерживают нативные запросы SQL. Это с одной стороны ограничивает их, с другой стороны открывает дверь когда стандартной генерации не хватает. Это обычная практика.

IT>А маппинг — это дело десятое, это вообще перекладывание из пустого в порожнее. BLToolkit умеет перекладывать что попало во что угодно. БД лишь частный случай. В этом принципиальное отличие от ORM.
Это не что-то новое. Это делает практически любой ORM. И версантовцы, и тот же Hibernate. Они все поддерживают кроме отдельного языка запросов, нативный SQL+stored procedures.

Здравствуйте, GlebZ, Вы писали:

GZ> Я вообще плохо понимаю зачем нужен LINQ.
Видишь ли... Настигала ли тебя мысль о том, сколько у тебя в проекте в среднем коллекций?
А Linq — это эффективный и простой способ делать запросы к этим коллекциям, ты все еще не понимаешь, зачем он нужен?

Здравствуйте, GlebZ, Вы писали:

GZ>Собственно поэтому ORM кроме объектного языка запросов поддерживают нативные запросы SQL. Это с одной стороны ограничивает их, с другой стороны открывает дверь когда стандартной генерации не хватает. Это обычная практика.
Угу, тока кривая, которая больше ограничивает, чем помогает, за что и не люблю всяческие гибернейты...
Продолжая цитировать того же Вастерса:

I particularly liked the "Architectural Truthiness" post by David Ing and the comment by "Scott E" in my comments section who wrote:

I've hiked up the learning curve for Hibernate (the Java flavor) only to find that what time was saved in mapping basic CRUD functionality got eaten up by out-of-band custom data access (which always seems to be required) and tuning to get performance close to what it would have been with a more specialized, hand-coded DAL.

As always, it's a matter of perspective. Here is mine: I went down the O/R mapping route in a project in '98/'99 when my group at the company I was working for at the time was building a new business framework. We wrote a complete, fully transparent O/R mapper in C++. You walked up to a factory which dehydrated objects and you could walk along the association links and the object graph would either incrementally dehydrate or dehydrate in predefined segments. We had filtering capabilities that allowed to constrain 1:N collections with large N's, we could auto-resolve N:M relationships, had support for inheritance, and all that jazz. The whole framework was written with code generation in mind. Our generators were fed with augmented UML class diagrams and spit out the business layer, whereby we had a "partial classes" concept where we'd keep the auto-gen'd code in one tree and the parts that were supposed to be filled manually in another part of the code tree. Of course we'd preserve changes across re-gen's. Pure OO nirvana.

.....

That said, I am not for or against O/R mapping. There are lots of use cases with a lot of CRUD work where O/R saves a lot of time. However, it is a leaky abstraction. In fact is is so leaky that we ended up not using all that much of the funkyness we put into our framework, because "special cases" kept popping up. I am pointing out that there are a lot of fundamental differences between what an RDBMS does with data and how OOP treats data.

Вообщем вот, чтобы потом еще не бегать: http://friends.newtelligence.net/clemensv/PermaLink,guid,92eaea8c-778d-4512-af03-d332785f65f5.aspx

GZ>Это не что-то новое. Это делает практически любой ORM. И версантовцы, и тот же Hibernate. Они все поддерживают кроме отдельного языка запросов, нативный SQL+stored procedures.
Нафига еще один язык запросов, типа объектный, когда есть SQL?
*Linq в этом плане выгодно отличается от всех остальных мапперов тем, что в нем этот язык работает не только для нарошных ORM-ных объектов, но и вообще для любых коллекций...

Здравствуйте, Merle, Вы писали:

M>Вообщем вот, чтобы потом еще не бегать: http://friends.newtelligence.net/clemensv/PermaLink,guid,92eaea8c-778d-4512-af03-d332785f65f5.aspx
Прочитал. Чувак сделал абсолютно прозрачный ORM и тем более на С++. Получилось то, что получилось. И поделом.
Современный ORM это значительно более сложная вещь. И не ограничевается CRUD. Основная его проблема в том, что он вместо того чтобы взять готовый ORM где уже проффесионально решены все эти проблемы, он решал их сам. К тому же, абсолютно прозрачный ORM — это гадость, поскольку подразумевает чистый Lazy Load. За такое убивать надо. Современный ORM — это не только CRUD.


GZ>>Это не что-то новое. Это делает практически любой ORM. И версантовцы, и тот же Hibernate. Они все поддерживают кроме отдельного языка запросов, нативный SQL+stored procedures.
M>Нафига еще один язык запросов, типа объектный, когда есть SQL?
Поясню.
Cервис должен обрабатывать ad-hook запрос. Хочу коллекцию объектов фильтрованных по 10 ссылке относительно объекта у которого параметр поставлен в true. Какие у нас варианты:
1. Сделать параметр в котором будет храниться строка SQL, или фильтр в терминах SQL references. Отметаем. Нельзя привязывать клиента к физ. базе SQL.
2. Делаем параметр в котором хранится фильтр в терминах логической модели.
Тут у нас есть варианты.
2.1 Мы отдаем это stored procedure, пускай он транслирует его в физ. термины и обрабатывает. Это значительно лучше чем п.1 но проблематичен. Во первых логика связи между реляционной и объектной схемой весьма сложна. Во вторых сложно делать парсинг запроса в T-SQL. В третьих мне придется также делать то же самое на PL/SQL.
2.2 Берем ORM(не важно DLinq или Hibernate) и строим запрос по логической схеме. Пускай он думает как сгенерить SQL в физических терминах. Его неглупые люди писали.
2.3 Загружаем все используемые объекты в коллекции, и с помощью Linq фильтруем. Даже пояснять не буду. Мрак.

M>*Linq в этом плане выгодно отличается от всех остальных мапперов тем, что в нем этот язык работает не только для нарошных ORM-ных объектов, но и вообще для любых коллекций...
Языки для XLinq, DLinq и Linq похожи но переносимы ли они?

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, GlebZ, Вы писали:

GZ>> Я вообще плохо понимаю зачем нужен LINQ.
M>Видишь ли... Настигала ли тебя мысль о том, сколько у тебя в проекте в среднем коллекций?
M>А Linq — это эффективный и простой способ делать запросы к этим коллекциям, ты все еще не понимаешь, зачем он нужен?
Не-а.
1. В большинстве случаев для запросов хватает стандартного Array,Find с делегатом. Благо запросы в большинстве своем, работают по одной коллекции.
2. Запрос будет неудачен, если коллекция не подгружена. А подгрузку Linq делать просто так, не умеет.
Есть в принципе один вариант использования. Если будет репозиторий объектов при работе в стиле ocasionally connected smart client. Тогда мощность Linq может быть востребована.

Здравствуйте, GlebZ, Вы писали:

GZ>Современный ORM это значительно более сложная вещь.
Это мы запишем в минус современным ORM..

GZ>И не ограничевается CRUD.
А где там хоть слово, про то что их ORM ограничивался CRUD? Наоборот, был весьма навороченой конструкцией...

GZ>Основная его проблема в том, что он вместо того чтобы взять готовый ORM где уже проффесионально решены все эти проблемы, он решал их сам.
Мужик, это был 98й год, какие готовые ORM?

GZ> К тому же, абсолютно прозрачный ORM — это гадость, поскольку подразумевает чистый Lazy Load. За такое убивать надо. Современный ORM — это не только CRUD.
Ты не понял, подвох в том, что ребята налабали афигительный ORM, который решал практически все проблемы работы с данными исключительно объектным способом... Pure OO nirvana. А оказалось, что все эти навороты нафиг не нужны, потому как слишком много "special cases", которые все равно надо обрабатывать в ручную..

GZ>2.1 Мы отдаем это stored procedure, пускай он транслирует его в физ. термины и обрабатывает. Это значительно лучше чем п.1 но проблематичен. Во первых логика связи между реляционной и объектной схемой весьма сложна.
Ничего сложного...

GZ> Во вторых сложно делать парсинг запроса в T-SQL.
Зачем?

GZ> В третьих мне придется также делать то же самое на PL/SQL.
Не придется. Я не верю в много БД-шные проекты, по крайней мере в те, где все это делает один человек.

GZ>2.2 Берем ORM(не важно DLinq или Hibernate) и строим запрос по логической схеме. Пускай он думает как сгенерить SQL в физических терминах. Его неглупые люди писали.
Какие-бы неглупые люди не были, они не могли предумотреть всех частных случаев, о чем и пишет Вастерс, а частных случаев, на практике, оказывается лишком много.

GZ>Языки для XLinq, DLinq и Linq похожи но переносимы ли они?
Ха, переносимы.. Я могу в одном выражении получить объект через DLinq, отфильтровать с помощю Linq и выдать результат через XLinq...

Здравствуйте, GlebZ, Вы писали:

GZ>Не-а.
Зря..

GZ>1. В большинстве случаев для запросов хватает стандартного Array,Find с делегатом. Благо запросы в большинстве своем, работают по одной коллекции.
Это тебе сейчас хватает, а вот дадут тебе Linq и не поймешь ты как раньше без него жил..

GZ>2. Запрос будет неудачен, если коллекция не подгружена.
Не надо там ничего грузить, и так хорошо.

GZ>Есть в принципе один вариант использования.
Да их там вагон.

Здравствуйте, Merle, Вы писали:

GZ>>Современный ORM это значительно более сложная вещь.
M>Это мы запишем в минус современным ORM..
Это мы никуда не запишем. Не будешь же ты отказываться от реляционных баз данных, из-за того что они сложны. Я не призываю делать ORM. Я призываю использовать ORM (когда он нужен ессно).

GZ>>И не ограничевается CRUD.
M>А где там хоть слово, про то что их ORM ограничивался CRUD? Наоборот, был весьма навороченой конструкцией...
Первый параграф списка. Да и подразумевается, fully transparent O/R mapper подразумевает Lazy Load на фоне LCRUD.

GZ>>Основная его проблема в том, что он вместо того чтобы взять готовый ORM где уже проффесионально решены все эти проблемы, он решал их сам.
M>Мужик, это был 98й год, какие готовые ORM?
CORBA.

GZ>> К тому же, абсолютно прозрачный ORM — это гадость, поскольку подразумевает чистый Lazy Load. За такое убивать надо. Современный ORM — это не только CRUD.
M>Ты не понял, подвох в том, что ребята налабали афигительный ORM, который решал практически все проблемы работы с данными исключительно объектным способом... Pure OO nirvana. А оказалось, что все эти навороты нафиг не нужны, потому как слишком много "special cases", которые все равно надо обрабатывать в ручную..
Это просто неумение готовить. В то время у меня были точно такие же заскоки.

GZ>>2.1 Мы отдаем это stored procedure, пускай он транслирует его в физ. термины и обрабатывает. Это значительно лучше чем п.1 но проблематичен. Во первых логика связи между реляционной и объектной схемой весьма сложна.
M>Ничего сложного...
Ну-ну. То выполнение простых SQL запросов не подходит, так как логика слишком сложна. То наоборот, это все просто. Определись.

GZ>> Во вторых сложно делать парсинг запроса в T-SQL.
M>Зачем?
Затем что наименования объектов и полей должны не зависить от физической схемы. А следовательно, ad-hook запрос не является SQL запросом, и его нужно обрабатывать.

GZ>> В третьих мне придется также делать то же самое на PL/SQL.
M>Не придется. Я не верю в много БД-шные проекты, по крайней мере в те, где все это делает один человек.
А кто говорил что один. Это нормальная практика тиражируемого софта.

GZ>>2.2 Берем ORM(не важно DLinq или Hibernate) и строим запрос по логической схеме. Пускай он думает как сгенерить SQL в физических терминах. Его неглупые люди писали.
M>Какие-бы неглупые люди не были, они не могли предумотреть всех частных случаев, о чем и пишет Вастерс, а частных случаев, на практике, оказывается лишком много.
В той схеме которую он сделал, частных случаев как грязи. В том же Hibernate их значительно меньше. Единственный стоящий вопрос — просадка производительности некоторых частных случаев.

Здравствуйте, GlebZ, Вы писали:


GZ>Это мы никуда не запишем. Не будешь же ты отказываться от реляционных баз данных, из-за того что они сложны.
Сложны? Да они просты как рельс...

GZ>Я призываю использовать ORM (когда он нужен ессно).
Когда нужен — не вопрос...

M>>А где там хоть слово, про то что их ORM ограничивался CRUD? Наоборот, был весьма навороченой конструкцией...
GZ>Первый параграф списка.
Первый параграф списка говорит о том, что CRUD очень просто использовать с ORM, но вовсе не то, что их ORM этим ограничивался.

GZ> Да и подразумевается, fully transparent O/R mapper подразумевает Lazy Load на фоне LCRUD.
Это ты подразумеваешь..

M>>Мужик, это был 98й год, какие готовые ORM?
GZ>CORBA.
Ага. точно. зашибись готовый ORM.

GZ>Это просто неумение готовить.


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

GZ>Затем что наименования объектов и полей должны не зависить от физической схемы. А следовательно, ad-hook запрос не является SQL запросом, и его нужно обрабатывать.
Тот же RFD справляется с этой задачей даже не почесавшись.

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

GZ>В той схеме которую он сделал, частных случаев как грязи. В том же Hibernate их значительно меньше.
Их как бы там не больше, в том же гибернейт.

Здравствуйте, GlebZ, Вы писали:

IT>Я недостаточно уверен в том, что способен нарисовать такую объектную модель, которую подхватить ORM и эффективно отобразит её на реляционную структуру.
GZ>Собственно поэтому ORM кроме объектного языка запросов поддерживают нативные запросы SQL. Это с одной стороны ограничивает их, с другой стороны открывает дверь когда стандартной генерации не хватает. Это обычная практика.

Из ненативных запросов SQL реальная польза может быть только от базовых CRUDL операций. Их в программе может быть достаточно много, чтобы их надоело набивать. Но генератор для них пишется за пару дней. В BLToolkit у меня на это ушло не больше времени. Дальнейшие навороты ORM вместе с фичами добавляют массу ограничений, правил, соглашений и условностей. И вот после того как ты им безукоризненно следовал тебе вдруг говорят, а вот здесь в самом интересном месте, тебе придётся воспользоваться нативными запросами. И тут ты понимаешь, что ты заточил всю архитектуру под конкретный ORM, а тебя обманули.

IT>>А маппинг — это дело десятое, это вообще перекладывание из пустого в порожнее. BLToolkit умеет перекладывать что попало во что угодно. БД лишь частный случай. В этом принципиальное отличие от ORM.
GZ>Это не что-то новое. Это делает практически любой ORM. И версантовцы, и тот же Hibernate. Они все поддерживают кроме отдельного языка запросов, нативный SQL+stored procedures.

А мапер из них можно выдернуть? Что если у меня источник XML, comma delimitted поток или объектная модель соседа?

Здравствуйте, Merle, Вы писали:

GZ>>Основная его проблема в том, что он вместо того чтобы взять готовый ORM где уже проффесионально решены все эти проблемы, он решал их сам.
M>Мужик, это был 98й год, какие готовые ORM?
TopLink, например. Был EJB CMP в Java, как зачаток ORM (совершенно неюзабельный, кстати).

GZ>>2.1 Мы отдаем это stored procedure, пускай он транслирует его в физ. термины и обрабатывает. Это значительно лучше чем п.1 но проблематичен. Во первых логика связи между реляционной и объектной схемой весьма сложна.
M>Ничего сложного...
Ага, конечно. У нас тут уже люди занимаются в проекте, где вся логика в SP (по заветам компании Microsoft и их MCSD) — могу написать их впечатления.

GZ>>2.2 Берем ORM(не важно DLinq или Hibernate) и строим запрос по логической схеме. Пускай он думает как сгенерить SQL в физических терминах. Его неглупые люди писали.
M>Какие-бы неглупые люди не были, они не могли предумотреть всех частных случаев, о чем и пишет Вастерс, а частных случаев, на практике, оказывается лишком много.
Для совсем частных случаев используем голые SQL-запросы и мапим их результат на объекты. В совсем крайнем случае — используем результат напрямую.

Смысл в том, что 90-99% обычных запросов замечательно генерируются ORMами. А это уже значительно упрощает работу.

Здравствуйте, Cyberax, Вы писали:

C>Ага, конечно. У нас тут уже люди занимаются в проекте, где вся логика в SP (по заветам компании Microsoft и их MCSD) — могу написать их впечатления.

SP не предназначена для написания бизнес логики. Это обсуждалось уже миллион раз. А вот в одном моём проекте народ без конца матерился на хибернейт. Тоже наверно не от хорошей жизни.

C>Для совсем частных случаев используем голые SQL-запросы и мапим их результат на объекты. В совсем крайнем случае — используем результат напрямую.

Крайние случаи ещё не стали повседневным делом?

C>Смысл в том, что 90-99% обычных запросов замечательно генерируются ORMами. А это уже значительно упрощает работу.

99? Верится с трудом. Вы что одни справочники выпускаете? Процентов в 70-80 поверю. Но оставшиеся 20-30% это как раз то на чём можно легко обломаться вместе с любым ORM. Зачастую такие запросы нужно тщательно отлаживать, гонять на реальных объёмах данных, иногда ради повышения производительности корректировать дизайн БД. А как насчёт запросов, в которых участвуют таблицы никак не представленные в объектной модели? Например, такое вполне возможно при подджоивании таблиц секьюрити. Они могут понадобиться практически в каждом запросе.

IT wrote:
> C>Ага, конечно. У нас тут уже люди занимаются в проекте, где вся логика
> в SP (по заветам компании Microsoft и их MCSD) — могу написать их
> впечатления.
> SP не предназначена для написания бизнес логики. Это обсуждалось уже
> миллион раз. А вот в одном моём проекте народ без конца матерился на
> хибернейт. Тоже наверно не от хорошей жизни.
В первый раз я тоже матерился. Во второй раз уже понял как надо
использовать Hibernate.

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

> C>Для совсем частных случаев используем голые SQL-запросы и мапим их
> результат на объекты. В совсем крайнем случае — используем результат
> напрямую.
> Крайние случаи ещё не стали повседневным делом?
99% повседневных задач — рутина, и если Hibernate возьмет ее на себя, то
на оставшийся 1% больше останется времени.

> 99? Верится с трудом. Вы что одни справочники выпускаете?
Нет. Например, сейчас люди пишут систему учета рабочего времени — там на
SQL только репорты (что вполне логично). Большая часть — достаточно
простые запросы.

> А как насчёт запросов, в которых участвуют таблицы никак не
> представленные в объектной модели?
Hibernate'у по сути нужны id-шники объектов и их типы (ну и еще возможно
часть полей, чтобы их не надо было лениво подгружать). Если из
результата вашего запроса можно получить эти данные — то никаких проблем
нет.

> Например, такое вполне возможно при подджоивании таблиц секьюрити. Они
> могут понадобиться практически в каждом запросе.
Используйте Oracle, там есть row-level security прямо вмонтированый в
базу

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

А если еще поставить простой app-сервер и добавить remote lazy loading,
то у нас получается почтиобъектная база.

Здравствуйте, Cyberax, Вы писали:

C>TopLink, например. Был EJB CMP в Java, как зачаток ORM (совершенно неюзабельный, кстати).
Во-во, к тому же проект у них был сишный..

C>Ага, конечно. У нас тут уже люди занимаются в проекте, где вся логика в SP (по заветам компании Microsoft и их MCSD) — могу написать их впечатления.
А кто говорит о логике в SP?

C>Смысл в том, что 90-99% обычных запросов замечательно генерируются ORMами. А это уже значительно упрощает работу.
Вот эти числа (90-99) очень серьезно зависят от конкретного проекта, и как правило все-таки существенно меньше. Причем здесь важно даже не процентное соотношение, а количество геморроя на строчку кода оставшихся от ORM процентов, которые все равно придется набивать в ручную...
Никто не призывает отказываться от ORM вообще, но и количество проектов, на которых использование готового ORM не заточенного именно под этот проект оправдано, гораздо меньше чем кажется на первый взгляд.