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

G>>>1) нельзя навесить хинты. Это вообще-то не правда, но люди упорно повторяют эту глупость.
AK>>А "хинт" это что?
G>http://msdn.microsoft.com/en-us/library/ms187713.aspx

Интересно. Не знал про эту фичу SQL.
А как "навесить хинты" через EF?

G>То есть способ не писать left join руками в Linq.
G>Так вот в EF появляется дополнительно вычисляемое поле, по которому потом идет сортировка.

А если left join написан руками, то проблем нет? То есть, всё решение заключается в избегании такого неявного JOIN, или там ещё что-то нужно?

AK>>А какие именно возможности SQL нельзя использовать через EF?
G>Например в linq нельзя написать MERGE оператор, использовать output выражения, табличные параметры для функций, FullTextSearch, ranking функции pivot\untivot и много чего еще. Большую часть можно обойти изобретением своих функий, но иногда проще тупо SQL написать.

А есть где-нибудь вот эта информация в сводном виде? Или какие-то исходные данные, из которых можно вывести таблицу — какие возможности SQL поддерживаются в EF, а какие не поддерживаются? У нас многое из перечисленного активно используется — и ranking-функции, и pivot, и merge, и табличные параметры. Мне надо бы рассказать команде про эти вещи и про обходные пути до миграции на EF. Да и самому нужно оценить целесообразность полной миграции — данных у нас очень уж много, некоторые операции по обработке данных длятся по нескольку часов. А такие вещи как MERGE, улучшают производительность (1 операция ввода/вывода вместо двух на SELECT + INSERT/UPDATE), так что часть обработки данных придётся оставить в хранимых процедурах до лучших времён.