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% если сесть и хорошенько подумать, то задача удивительным образом декомпозируется и теряет свою «реляционную» привязанность. Зачастую, я уже неоднократно с этим сталкивался, проблема кроется в «реляционном» мышлении. Когда человек автоматически любые данные старается сразу разложить по таблицам и организовать между ними связи. С одной стороны круто, но с другой — тупик. Надо мыслить шире, реляционная модель крутая, но одна всего лишь одна из, и не панацея.