Сон Веры Павловныskiped...
С реляционными базами данных. Потому как появились NoSQL базы, где приниципы работы несколько иные.Дык про NoSQL базы тут вроде как речи не идёт.

Алексей К...Лучше видоизменить запрос или иметь актуальную статистику, чем использовать хинты.Хыыыы, вот прикол...
А предположим, что у Вас для таблицы, которая интенсивно используется в разных отчётах созданы соответствующие индексы.
Вы знаете, оптимизатор иногда таки не может корректно нарисовать план исполнения в силу его собственной статистики и тогда начитаются весёлые звездопляски с профайлером и прочим непотребством... А в это время тебе пользователи плешь проедают, потому как одно чудо запустило тяжеловесный отчёт, а другое не может в это время документы проводить, из-за того что тупо сервак в силу не оптимального запроса отдал ему ("отчётному" запросу)более чем дохрена ресурсов...
Вот тогда и приходится хинтами указать с какими индексами и в какой последовательности выбирать...
Сделаете это в LINQ+ORM - поставлю коньяк.

Алексей К...Я понял Ваше сообщение так: "LINQ+ORM мне не нужны, у меня и без них всё достаточно плохо". Не обольщайтесь
Абсолютно неверно поняли...
Где я сказал, что у меня и так всё плохо и поэтому я не использую LINQ + ORM?
Передёргивать-то не надо...

Я лишь сказал, что используя LINQ+ORM у Вас не получится сделать тонкие настройки в сложных и интенсивных выборках. И если сможете это сделать, то я поставлю коньяк...

Видимо выпью коньяк сам

PS. Кстати, LINQ в .NET я действительно не использую т.к. нет в этом необходимости, а вот ORM по полной, и меня это как-то не особо напрягает (неиспользование LINQ в .NET), мне знаете-ли аналога LINQ в виде OPEN SQL в ABAP/4 более чем за глаза хватает. Только вот в OPEN SQL я в отличие от LINQ могу указать хинты в запросе... это чтобы не напряжно было серверу и пользователям...

Алексей Кпропущено...Здесь:А предположим, что у Вас для таблицы, которая интенсивно используется в разных отчётах созданы соответствующие индексы.
Вы знаете, оптимизатор иногда таки не может корректно нарисовать план исполнения в силу его собственной статистики и тогда начитаются весёлые звездопляски с профайлером и прочим непотребством... А в это время тебе пользователи плешь проедают, потому как одно чудо запустило тяжеловесный отчёт, а другое не может в это время документы проводить, из-за того что тупо сервак в силу не оптимального запроса отдал ему ("отчётному" запросу)более чем дохрена ресурсов...
Вот тогда и приходится хинтами указать с какими индексами и в какой последовательности выбирать...Опять передёргивания и домыслы...
Хотите пользовать LINQ, используйте, кто-ж Вам запретит-то...
А мы уж так, по старинке, сами будем определять ЧТО и КАК должно исполняться на сервере, а не отдавать это на откуп "индусам", которые LINQ "срисовали"...

PS. Кстати, за попытки необоснованной "оптимизации скорости" выборки путём вытаскивания данных из связанных таблиц на "клиента" и последующего их "соединения" бью своих нещадно ложкой по лбу. Но к LINQ это ровным счётом никакого отношения не имеет, это можно устроить и без оного...