sheichЕсли я пишу запрос на SQL я всегда могу использовать все преимущества индексирования, расширенных возможностей T-SQL или PL/SQL и добиться максимальной скорости

Дыма без огня не бывает. Если тебе приходится писать такие зубодробительные запросы, значит изначально БД была спроектирована через одно место. Значит поддержка этого УГэ будет стоить бешенных денег, сил и тонны нервов разработчиков, особенно тех, кто придёт на проект позже. Значит любое изменение с структуре БД это поход пешим шагом по минному полю.

Я могу добиться максимальной скорости — такой подход уместен на гонках, где за долю выигранных микросекунд можно отхватить увесистую медаль. Но в реальных приложениях в реальном мире решает совершенно другое. Простота, понятность, сопровождаемость, тестируемость. Это всё часто идёт вразрез с «расширенными возможностями T-SQL/PL-SQL». Но если очень хочется — никто не запрещает.

Есть ряд задач, ориентированных на обработку данных. Но их меньшинство. И обычно их можно выделить и инкапсулировать от остального комплекса. Там уместно применение расширенного SQL, но там LINQ точно нафиг не сдался.


sheichЯ тут случайно вместо того, что бы запринтовать в лог значения полей коллекции вывел SQL-запросы, которые генерит LINQ для получения поля этой коллекции и ужаснулся... И понял, почему LINQ так тормозит.

Есть несколько причин, почему тормозит LINQ:

1. Кривая структура БД, изначально не подходящая для задач, решаемых LINQ
2. Запрос LINQ составлен так, как он был бы составлен в SQL, тогда как LINQ не предназначен собирать данные из таблиц, ему суждено оперировать коллекциями и объектами, которые друг с другом изначально связаны (а через JOIN как в SQL)
3. SELECT N+1

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


sheichВобщем, я не вижу какого-то адекватного, простого использования LINQ в случае работы с большими массивами данных в БД.

Всё зависит от изначальной задачи. Если массив данных это коллекция объектов, проблемы нет. А если это просто какой-то набор таблиц, спроектированный через одно место, и чтобы получить какие-то данные, надо выкатить листинг SQL на пару страниц, то это уже совершенно к другому врачу

Если задача — пережевывать огромную кучу данных, где нет целостных объектов, а просто какие-то данные, разбросанных по таблицам без общего соблюдения принципов нормализации, то конечно, тут нафиг LINQ не упёрся.

sheichОК, она пишет за меня SQL и вытянуте данные переводит во временные (в памяти) коллекции. Потом, видимо я должен оперировать уже коллекциями. Но они же, вот, не могут быть проиндексированы, например, в отличие от таблиц?...

Странный вопрос. Зачем их индексировать в памяти? Какая изначальная задача?

Сравнивать LINQ vs SQL — уже по сути неправильно.

Алексей КПотому что запросы писать на LINQ удобнее, модифицировать такой код удобнее.

Ты не напишешь на LINQ то, что можно написать на SQL, поэтому LINQ быть полной заменой SQL не может. Не неси чепуху.


Алексей ККакая моя постановка задачи неправильная? Ты о чём?

Вот такая: «Я пишу на LINQ, потому что на нём писать удобнее, чем на SQL, и модифицировать такой код удобнее».

Бред безумца. Даже не буду эти детские наивные глупости комментировать. Вроде уже не джуниор, а такое выдаёшь.