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

G>Выкини NHibernate, возьми EF или linq2db, там нет таких проблем.
Вы будете смеятся, но мы до этого выкинули EF. Был болезненный переход на NH... У EF тоже куча недостатков, например он не позволяется получить вам чистые доменные объекты. То есть в классах доменных сущностей у вас присутсвуют ссылки на типы из EF, а это не правильно. Я, например, должен свободно использовать доменную сущность на клиенте не потащив туда ORM... Да и запросы у EF просто жесткач некоторые, NH в этом плане получше, хотя тоже косячит.

G>>Погодите. Наиболее типичный пример у меня в базе лежит 10 ГБ записей в табличке, мне нужно найти в этой куче удовлетворящие моему критерию умножить поле на два и вставить записи в две другие таблички. Решение с хранимой процедурой очевидно.
G>Это реальный сценарий? Можешь описать его в терминах пользователя?
G>Или ты нафантазировал и считаешь, что ради такого стоит весь crud в хранимках делать?

Не верите. Окей, вот вам реальный бизнес сценарий. Есть компьютерная сеть в которой есть сетевые узлы и пользователи. Они имеют связи между собой, мы это все храним в базе и даем возможность через наше приложение админить.
Таблицы User(Id, Name, Property), Network_Node(Id, Name, Property), User_User(User1Id, User2Id), Network_Node(Node1Id, Node2Id), UserOnNode(NodeId, UserId)
В нашей базе 70000 узлов по одному пользователю на узле (для простоты). Пользователи связаны все со всеми. Для некоторый (приблизительно половины) узлов был проставлен признак Prorepry — теперь нужно добавить для таких узлов на которых есть зарегестрированные связанные пользователи . Особенно посчитайте размер таблицы User_User, это приятный момент


G>>>Код на SQL который более лаконичный и лучше читается не имеет никакого отношения к высокой производительности.
G>>Ну это был второй аргумент: 1. производительность, 2. локаничность и выразительность. Все таки SQL очень мощный он позволяет вам запросить что вам нужно, а не как извлеч данные.
G>Ок, напиши запрос, удовлетворяющий следующим условиям:
G>1) Если пользователь админ, то ему показать все записи
G>2) Если пользователь не админ, то
G> — показать ему записи, где пользователь = автор
G> — или автор записи входит в группу друзей текущего пользователя
G> — и записи не должны быть скрыты
G>3) Записи должны быть отфильтрованы по категории, которую выбрал пользователь (id категории — параметр запроса, может быть пусто)

G>При этом запрос должен быть максимально лаконичным и быстрым.
Я считаю — прекрасно, практически на естественном языке

select r.id, r.name
from rows as r
where r.IsHidden = false and 
      (exists(select * from Administrators a where a.User = r.User) or 
       exist(select * from UserFriends uf where uf.User = r.User and r.Friend = @currentUser ))