На архитектурных картинках обычно рисуют красивые схемы по разделению слоев представления, бизнес логики и данных. Голубая мечта начинающего разработчика - использовать одну среду для разработки всех слоев и забыть про необходимость знаний реляционных СУБД, сведя их назначение к интеллектуальной файловой системе. Слово SQL (сиквел) вызывает негативные ассоциации, а уж про триггеры или процедурные расширения оного и говорить не приходится. И тут приходят добрые дяди, с книжками Фаулера и других полубогов под мышкой, заявляющие новичкам примерно следующее: "Парни, реляционные СУБД - пережиток эпохи 30-летней давности. Сейчас все строится на ООП. И есть чудесная штука - отображение с реляций на объекты (object relation mapping). Начните использовать ее и забудьте про жестокое наследие прошлого!"

Парни принимают предложение. Дальше эволюция разработки системы примерно следующая.

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

Начинаем строить предметную модель. Добавляем классы, свойства, связи. Генерируем структуру БД или подцепляемся к существующей. Строим интерфейс управления объектами типа "создать, выбрать, модифицировать, удалить" (CRUD: create, retrieve, update, delete). Все достаточно просто. По крайней мере кажется немногим сложнее, чем работа с DataSet. Тем кто о них знает. Так как многие и не подозревают о существовании табличных форм жизни данных в приложении кроме DBGrid.

Как только разработчики реализовали CRUD-логику, начинается основное действо. Безболезненно использовать сиквел уже нельзя. Надо использовать собственный язык запросов ORM. Нестандартный, кривой, созданный в так называемом эволюционном дизайне. То есть по принципу добавления новых фишек по мере надобности. Если он, язык, вообще имеется в данном ORM, конечно. К тому же вдруг оказывается, что собственный язык запросов генерирует далеко не самый оптимальный сиквел.

Когда БД относительно небольшая (сотня-другая тысяч записей в наиболее больших таблицах), а запросы не слишком сложны, то даже неоптимальный сиквел в 80% случаев прокатывает. Пользователь немного подождет.

Однако, запросы типа "выбрать сотрудников, зарплата которых в течение последнего года не превышала среднюю за предыдущий год" уже вызывают проблемы на уровне встроенного языка. Тогда разработчики идут зачастую единственно возможным путем: выбираем коллекцию объектов и в цикле ее фильтруем руками, вызывая методы связанных объектов. Количество небольших SQL-запросов к СУБД при такой обработке коллекций может исчисляться десятками тысяч.

Примерно так же это делалось с табличными данными разработчиками на Clipper в конце 80-х годов. Там это называлось "навигационная обработка". Думаю, термин уместен и здесь.

Суть в том, что в эпоху перехода с Клиппера на РСУБД многие приложения и их разработчики продолжали использовать навигационный подход. И приложения работали медленно, зачастую блокируя многопользовательсткий доступ. Потому что для эффективной работы с РСУБД нужно использовать Р(реляционные) подходы. Множественные подходы. Множественные не в смысле "много подходов", а ориентированные на обработку множеств. Предполагающие хотя бы минимальную тренировку мозгов разработчика на задачки из теории множеств.

Дорогие коллеги, учите матчасть. И будет сиквел вашим верным другом на долгие времена.

В контексте доступа к реляционным данным (похороненный микрософтом LINQ to SQL) это была, как оказалось, никому не нужная попытка встроить "сильно упрощенный сиквел" в код на сишарпе.

В контексте ORM/ОРП проекций на долговременные объекты (LINQ to entities) по сути ничего не меняется, все описанное выше остается. За исключением большей простоты обработки коллекций на клиенте СУБД. Раньше разработчику нужно было явно загрузить коллекцию объектов из БД и после начать обрабатывать ее в цикле. Теперь можно сделать это более быстро средствами LINQ, т.к. императивного кода придется писать меньше. Это позволит разработчикам писать за то же самое время большее количество неоптимального говнокода.