Алексей Кsphinx_mv Эффективного способа перевода SQL-запросов в C# нет."Рыба есть, ловить надо уметь". (ц)"Тут рыбы нет!" (ц) директор стадиона.
Обратите ЕЩЕ раз внимание на выделенное... То, что LINQ не в полной мере даже просто покрывает функционал "стандартного" SQL - это плохо опровергаемый факт.

И не забудьте, что когда Вы таки используете LINQ-то-"какая-то СУБД/ORM/etc." Вы все-таки транслируете не SQL в LINQ, а LINQ в SQL - что есть "немножко разное"...

При этом я пока еще не предлагаю принять во внимание эффективность получения результатов для LINQ-запросов ии "конечных" SQL-запросов к базе данных. Ну, хотя бы потому, что иначе как минимум для SQL-запросов придется вспомнить, что на разных серверах БД "эффективный" синтаксис SQL-запросов тоже разный...

Алексей ККифирчикИменно "сложные запросы" - конечно же остались в ХП и вью.Любой сложный запрос делится на множество простых. Просто мысль... :-)Ну-ну... Как это "по-нашему" - сначала создаем себе проблемы, потом героически их преодолеваем...
Тянем на клиента практически "сырые" данные, а потом их "сливаем" между собой - это, ну, ОЧЕНЬ практично... Даже для выборок из таблиц на пару сотен тысяч записей... А потом начинаем жаловаться, что сервер БД захлебывается от запросов, что сеть слабая, что памяти не хватает и т.д. и т.п...

Кифирчикsphinx_mvБанальные сортировки, фильтрация и поиска в данных - и это практически все, что умеет LINQ.
Самой прикольное, что все это можно делать совсем без использования LINQ - и со времен царя гороха.
Можно, но писать в духе
var cars1 = db.Cars.Where(c=>c.CarMake == "Ford").Select(c=>c.CarID);
на выходе я получу запрос "select CarID from dbo.Cars where CarMake = @p". (За сложными запросами наблюдал через профайлер, вполне адекватный SQL получается)Соединять таблицы (join)? Выбирать связанные по "мастер-деталь"? "Не верю!" (с) :)
Кифирчики это ИМХО удобнее чем .NET DB апи (времена царя гороха) использовать, следить чтоб с названиями опечаток не было, параметры в запросах и т.д.Пфффф... :)
Не надо за названиями следить и за опечатками: интелисенс для баз данных существует тоже со времен царя гороха - включая переменные и параметры запросов и хранимых процедур с функциями.
Кифирчикс Linq - когда нужны "простые" запросы, ИМХО компактнее и читабильнее.Ну, скажем так... Очень зависит от степени кривизны рук архитекторов и разработчиков как приложения, так и ORM-фреймворка.

Как-то помогал разбираться с "непонятками" на сервере БД - десяток пользователей, доступ через WEB-интерфейс, жалкая сотня тысяч документов в базе (и постороннее коммерческое приложение).

Наблюдалось, что при выполнении некоторых выборок по условиям, введенными пользователями в приложении, сервер баз данных попадал в ступор - почти 100% загрузка по всем основным используемым ресурсам - процессор, диск, сеть... Начали разбираться с этим WTF'ом через профайлер - посто нужно было ткнуть сомневающихся носом во вполне ожидаемую ситуацию...
Чтобы выбрать данные по критерию, сначала формировался список данных из всех связанных таблиц: по общему списку документов список из множества атрибутов сначала дополнялся данными отдельными маленькими простыми запросами из базы. Потом по итоговому результату на WEB-сервере фильтрация по критериям. Иногда подобные "ну, очень легкие" обработки запускались несколькими пользователями параллельно. В итоге все это "счастье" начинало работать крайне медленно, и пользователи, не дождавшись результата, прерывали выполнение своих запросов... Но приложение на веб-сервере продолжало насиловать сервер баз данных. "Экстаз" сервера БД продолжался минут по 10-15 даже после отключения всех пользователей...

К чему это я? А к тому, что попасть в такую ситуацию при использовании даже "правильного" ORM-фреймворка проще пареной репы - даже для самых продвинутых разработчиков.
Кифирчикsphinx_mvФэншуй заключается в том, чтобы знать и уметь пользоваться инструментом - Вы про такой подход в курсе?
Окай, 2топик стартер. знать и использовать стандартные инструменты прежде чем изобретать велосипед или использовать в проекте сторонние поделки.
:)
Кифирчикsphinx_mvАга... И после переноса на LINQ все это стало работать лучше...
Возможно, мне бы и захотелось в это ПОВЕРИТЬ, но, к сожалению, вот именно в этом вопросе я непробиваемо убежденный атеист. :)
Нет, работать быстрее не стало, очевидно что какое-то время добавилось на трансляцию (порядок цифр - до 700мс, после 940мс).+30% времени на выполнение отдельнго запроса?! 8-0
С моими объемами транзакций в секунду меня просто уволят без выходного пособия после такой "оптимизации"...
КифирчикДля пользователя это незаметно, таже транзакция, а с кодом стало проще работать и отлаживать. Банальная возможность пройтись дебаггером и использовать в коде #region сильно все упростили.Скрывать блоки кода в хранимых процедурах, как ни странно, мне (как-то) удается без использования #region... :)
Про дебагер вроде бы уже было...
Про тестирование я упоминал? Если нет, то и оно доступно - как ручное, так и полностью автоматизированное.
КифирчикКод выполняется в апп сервере, появилась возможность использовать не только данные базы. Раньше для каждого объекта пилилась своя ХП (своего рода кастомизация), и плыли по составу экземпляры БД, теперь свой XML с настройками логики, схема БД - на 99% унифицирована.
Нет у меня доменной авторизации к SQL чтоб использовать его отладчикЭто какие-то ужасы из параллельной реальности...
Права правильно раздать разработчиков на отладочном сервере баз данных не вариант?
Кифирчикда и запускать хп из SMS и её отлаживать - менее удобно чем во время работы приложения.Относитесь к БД как к отдельному модулю, который может разрабатываться и отлаживаться отдельно от всех остальных.