Здравствуйте, Gattaka, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>Типичное приложение — это CRUD. В простом приложении CRUD это 100% всей работы с базой, в сложном — не менее 60% по моим подсчетам.
G>Даже CRUD для ORM не такое простое дело, например в том же NHibernte при этом нужно открывать именно его транзакции обязательно. Иначе текут коннекшены, он их в таком случае не освобождает.
Выкини NHibernate, возьми EF или linq2db, там нет таких проблем.
G>Погодите. Наиболее типичный пример у меня в базе лежит 10 ГБ записей в табличке, мне нужно найти в этой куче удовлетворящие моему критерию умножить поле на два и вставить записи в две другие таблички. Решение с хранимой процедурой очевидно.
Это реальный сценарий? Можешь описать его в терминах пользователя?
Или ты нафантазировал и считаешь, что ради такого стоит весь crud в хранимках делать?
В реальности у тебя будет сценарий такой:
1) Выбор строк по критерию и отображение на экране
2) Вызов этой самой бизнес-логики указанных пользователем строк.
Тут логика в приложении на два порядка лучше отработает.
G>Решение с ORM — нужно вытащить данные из БД, матерелиазовать их в сущности, сделать бизнес логику и поехали опять в базу на вставку. Вот за счет таких переливаний ORM и проигрывает, причем сильно. Но зато бизнес логика не в хранимках и "красиво" 
Только в жизни подобный сценарий встречается в OLAP-системах, где вообще нет "приложения".
G>>Код на SQL который более лаконичный и лучше читается не имеет никакого отношения к высокой производительности.
G>Ну это был второй аргумент: 1. производительность, 2. локаничность и выразительность. Все таки SQL очень мощный он позволяет вам запросить что вам нужно, а не как извлеч данные.
Ок, напиши запрос, удовлетворяющий следующим условиям:
1) Если пользователь админ, то ему показать все записи
2) Если пользователь не админ, то
— показать ему записи, где пользователь = автор
— или автор записи входит в группу друзей текущего пользователя
— и записи не должны быть скрыты
3) Записи должны быть отфильтрованы по категории, которую выбрал пользователь (id категории — параметр запроса, может быть пусто)
При этом запрос должен быть максимально лаконичным и быстрым.
