sheichТак какие же подходы примеными на практике?
Поправьте, если неправ

Для начала необходимо понять, что LINQ это не альтернатива SQL, никогда ей не была, и вовсе не задумывалось таковой. Поэтому сравнивать SQL vs LINQ — вообще не корректно, в принципе. Это как сравнивать пилу с молотком.

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

Обычно, если данные хорошо нормализованы и укладываются в объектную модель приложения, то запросы на LINQ писать гораздо легче, они понятнее, логичнее и проще, чем аналог на SQL.

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

Алексей КПравильно, если планируем применять LINQ для генерации SQL.

Так почему бы тогда сразу не писать SQL? Правильная постановка задачи -- уже пол решения, у тебя постановка неправильная, поэтому и выводы в корне неправильные.

stomskyНу, например, потому, что SQL-запросы писать в коде на C# бывает менее удобно и производительно, чем на LINQ. Хотя дело вкуса, конечно.
Я вот и SQL-ем и LINQ-ом пользуюсь. Причем SQL-ем чаще, но только потому, что знаю его лучше, чем LINQ.

Я вообще не пользуюсь SQL-ем, кроме крайне специфичных случаев. Не потому что LINQ мне кажется более выразительным, чем SQL. А потому, что на LINQ решаются задачи, специфичные для LINQ, а именно — извлечение данных объектов. На практике выяснилось: то, что раньше решалось сложными SQL с листингом не несколько страниц, проще решается избыточным хранением данных в нужном виде.

Например,

SQL-style: десятки JOIN-ов (INNER, LEFT/RIGHT, OUTER) с массой EXISTS/WHERE подвыборками, группировоками, и тому прочее.

LINQ-style: ведение параллельно в БД отдельной плоской структуры всех необходимых данных, к которой осуществляется простой доступ как к коллекции. Да, избыточно. Да, слегка снижается скорость прямой записи/изменений (это если не делать отложенную очередь). Но, крайне эффективные молниеносные выборки, быстрее, чем SQL-style, местами на порядки. Очень понятно для сопровождения, поддаётся контролю и полному тестированию. Не зависит от природы СУБД.

Промежуточный способ: сделать SQL-View и отразить её, как таблицу. Удобно для тех, кто способен понимать только SQL-style, удобно, когда задачу надо решить экстремально быстро и плевать на последствия. Неудобно для сопровождения, практически не тестируется модульно, грозит большим увесистым долгом. Сложно транслировать решение на другую СУБД или вообще на NoSQL.

sheichя всегда шел по пути кесарю-кесарево: sql - для таблиц в бд
sheichа тут... при работе с linq все перемешано.. бд используется просто как помойка с простыми таблицами, а приложение гоняет данные и запросы туда сюда, "думая", что имеет дело с местными данными
идея сама по себе странная

А ничего и не поменялось. SQL — это средство для работы с СУБД. Если говорить о БД, то «помойка с простыми таблицами» это и есть самая суть БД. Да, именно. Хранилище данных. Чем проще — тем лучше.

Или вы не получите удовлетворения от результата работы, если все слишком просто? Надо обязательно усложнить! Триггеры! Табличные процедуры! )))))

В LINQ ничего не перемешано, это уровень абстракции.

Правильно было бы провести такую аналогию:

asm → C/C++ (реализация языка написана на ассемблере)
SQL → LINQ (данные из БД LINQ достаёт посредством SQL)

Никто же сейчас не нудит, дескать, чего это никто на ассемблере не кодит, все на языки высокого уровня перешли. Даже грустно как-то


sheichно подход у нынешнего работодателя такой(

При чём тут работодатель? Обойдите свой вопрос с другой стороны и посмотрите с другой точки зрения. Ведь даже памятник Пушкину с определённой стороны это всего лишь каменная жопа

sheichи за субд обидно )) ладно еще, если в целях хранилища используется mysql, там или еще чего. но когда mssql или oracle превращают в простые свалки... это как микроскопом солить огурцы

Если хочется делать упор на SQL, ищите работу, где потребуется много работы непосредственно с базой данных. Таких компаний достаточно много, предложений достаточно, да и задачи соответствующие, где это может быть актуально — есть.

Кесарю — кесарево. Сами сказали.

Перегонщик перекупкисильно категорично. часто запросы для DTO реально сложные (всякие аналитические функции и пр.) и заточены на обработку именно "реляционного отношения", а не "списка объектов". к тому же обратное отображение O->R для них не надо.

И в 90% если сесть и хорошенько подумать, то задача удивительным образом декомпозируется и теряет свою «реляционную» привязанность. Зачастую, я уже неоднократно с этим сталкивался, проблема кроется в «реляционном» мышлении. Когда человек автоматически любые данные старается сразу разложить по таблицам и организовать между ними связи. С одной стороны круто, но с другой — тупик. Надо мыслить шире, реляционная модель крутая, но одна всего лишь одна из, и не панацея.

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, и модифицировать такой код удобнее».

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