Важен ли SQL, если я хорошо знаю фреймворки ORM? [закрыто]


51

У меня нет серьезного опыта работы с SQL, и я даже ненавижу писать SQL вместо LINQ. Я достаточно счастлив с ОРМ.

С точки зрения работодателей и сектора, важно ли знать SQL? Должен ли я освоить это? Являются ли компании, которые предпочитают чистый SQL, а не ORM, "динозавром" в мире программирования?


14
Я чувствую себя старым. SQL был абстрагирован настолько далеко, что теперь вы можете серьезно задать этот вопрос.
Марк

11
@Mark: Возможно, вы можете серьезно задать вопрос, но ответ остается прежним.
Адам Робинсон

30
знание арифметики все еще важно, если я могу использовать калькулятор?
Стивен А. Лоу

4
NHibernate без знания SQL Profiler и того, как его пощекотать, чтобы использовать JOIN, - это джихад производительности, ожидающий вашего сервера базы данных
Chris S

2
Нужно ли знать HTML, если вы можете использовать Dreamweaver?
Тулаинс Кордова

Ответы:


63

Это трудно объяснить многим программистам, потому что, если вы знаете только базовый SQL, то это действительно не дает вам большого преимущества перед опорой ORM. Однако более продвинутые концепции SQL являются важной частью различий между приложениями, которые просто работают, и приложениями высокого качества (в частности, быстрыми и надежными).

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

  • Рекурсивные и / или иерархические запросы
  • Необязательные параметры (в частности, перевод их в предикаты диапазона)
  • Пользовательские типы данных
  • Платформо-зависимые типы (иерархия SQL и TVP, массивы Oracle и вложенные таблицы и т. Д.)
  • Пакетные вставки / обновления / upserts / delete
  • Индексные подсказки
  • Подсказки по блокировке (особенно обновления блокировок и грязное чтение)
  • Обработка ошибок
  • Внешние объединения - их результирующие наборы плохо соответствуют модели ООП, многие ORM имеют свой собственный язык запросов, но это похоже на знание самого SQL;
  • Модуляризация через хранимые процедуры и пользовательские функции, особенно встроенные пользовательские функции и запросы CROSS APPLY
  • Использование OUTPUT / RETURNING для размещения данных в нескольких таблицах
  • Эффективные пейджинговые запросы
  • Запросы на основе оконных функций (rownum, rank, partitions)

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

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


Я согласен с большинством ваших замечаний, но относительно внешних объединений: да, они плохо отображаются в ООП, но я думаю, что эквивалент ООП (например, GroupJoinв LINQ) намного лучше.
svick

@svick: у него есть свои применения, но это не одно и то же. Попробуйте эмулировать полное внешнее соединение с GroupJoin.
Аарона

Да, это не одно и то же. И я думаю, что вам нужно больше всего времени на самом деле GroupJoin. Просто люди, которые привыкли к SQL, сразу думают о внешнем соединении в этих случаях, а затем спрашивают, как перевести это в LINQ. Это не правильный подход. Вы не должны пытаться перевести ваш SQL в LINQ, вы должны перевести то, что вам нужно напрямую.
svick

@svick: Спасибо за совет. Ненавижу поднимать рейтинг, но после годичного перерыва я по-прежнему являюсь одним из лучших разработчиков SQL и Linq по переполнению стека, поэтому я почти уверен, что понимаю разницу в подходе. Полные объединения редки, но иногда они на самом деле то, что вам нужно, и в Linq просто нет аналога. Это довольно грязно и неэффективно, чтобы получить тот же набор результатов , независимо от того, как он структурирован .
Аарона

Кажется, мы на самом деле согласны. В большинстве случаев вам не нужно внешнее соединение. Но когда вы делаете, это трудно перевести на LINQ.
svick

90

Абсолютно! SQL по-прежнему является лингвистическим языком баз данных, и хотя вы можете многое сделать с ORM, вы должны понимать SQL, чтобы понимать решения, принимаемые ORM, и SQL, который они генерируют. Кроме того, есть еще много вещей, которые вы должны делать с пользовательскими SQL и хранимыми процедурами. Извините, нет бесплатного обеда.


6
На самом деле. Вы должны знать, например, влияние различных операторов соединения и как это влияет на производительность.
Хирон

15
+1 Нет бесплатного обеда! Что со всеми вопросами, в основном спрашивающими, нормально ли невежество?
Бензадо

7
@benzado: Не то чтобы я думал, что это оправдано для SQL, но вы должны выбрать незнание некоторых вещей; Есть слишком много технологий (даже хороших!), чтобы действительно знать их все. Поэтому я думаю, что все в порядке, чтобы спросить: «Не нужен ли X, если я действительно хорошо знаю Y или я делаю Z?»
Крейг Уокер

2
@Creig Я согласен, что есть слишком много, чтобы учиться, но программист действительно должен иметь базовые знания ниже уровня, на котором он работает.
Бензадо

2
Базы данных @Craig Walker являются критически важными знаниями для большинства бизнес-приложений.
HLGEM

25

Да, вам все еще нужно знать SQL. ORM являются очень утечкой абстракции и не предоставляют доступ ко всем возможностям SQL. Для игрушечных приложений вы можете быть в порядке с ограниченными знаниями SQL. Для корпоративных приложений вы должны понимать базу данных, чтобы получить достойную производительность от ORM. Кроме того, существует множество задач, которые гораздо легче выполнить с помощью SQL, чем с языком приложения. Я видел, как Java-программисты тратят дни на написание кода, чтобы сделать что-то, что можно было бы написать в SQL за час. Знание SQL очень полезно для тех, кто пишет приложения, использующие реляционную базу данных.


14

Навыки SQL - это обязательный навык в IT. LINQ - это технология Microsoft Only. Использование SQL выходит за рамки разработки веб-приложений и приложений клиент-сервер. Вы не можете моделировать базы данных и делать ETL, если вы не очень хорошо разбираетесь в SQL. Вам может не понадобиться осваивать диалекты SQL, используемые в ORACLE и SQL Server для их продуктов Data Warehous, но вы должны знать стандартный SQL. Основы SQL просты, есть множество материалов, с которых можно начать.


1
Любой, кто знает, как работает LINQ, сможет выучить базовый SQL за день. Это ужасный аргумент для изучения SQL.
Борис Янков

6

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

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


Хотя я согласен, что знание SQL очень полезно - в основном обязательно - я не согласен с вашими соображениями. Исходя из этого, вы должны знать ASM и архитектуру своего ЦП, прежде чем писать какую-либо программу, потому что языки высокого уровня упрощают работу, но являются инструментами (для абстрагирования), поэтому, если вы отказываетесь изучать инструкции и архитектуру вашего процессора, вы не будете использовать бизнес компьютер. <--- Не имеет смысла. Настоящая причина, по которой вам это нужно, заключается в том, что инструменты ORM все еще находятся в зачаточном состоянии; Я не удивлюсь, если через 5-10 лет знание SQL перестает быть необходимым
Томас Бонини

Языки высокого уровня построены таким образом, что они не позволяют вам знать о базовой архитектуре, правда. Это возможно, потому что домен соизмерим с базовой архитектурой. ОРМ, однако, это другое дело. Я большой поклонник ORM, но я не думаю, что когда-нибудь настанет день, когда вы сможете использовать один, не зная SQL (или того, что использует базовая БД). Объектная и реляционная модели принципиально несопоставимы, и я думаю, что всегда найдутся концепции, которые не переводятся из одного в другой. Кроме того, я говорю о сегодняшних ОРМ, а не о будущем
Марнен Лайбоу-Козер

3
+1: «Если вы отказываетесь изучать SQL, у вас нет никакого дела, касающегося баз данных SQL, с ORM или без него, и вы должны найти другой тип работы».
вектор

2
Я бы проголосовал за это миллион раз, если бы мог. слишком много людей, которые не имеют никакого отношения к базам данных SQl из-за их общей некомпетентности и непонимания того, что они делают. Они добиваются успеха везде, где бы они ни находились, создавая великолепные рабочие места и создавая отчеты (на основе которых принимаются реальные бизнес-решения), которые дают результаты, даже не замечая, потому что они преднамеренно не знают о SQl, как будто это своего рода знак чести - задерживать базу данных это имеет решающее значение для их приложений.
HLGEM

1
+1 за «инструменты (для абстрагирования вещей, которые вы знаете), а не костыли».
Шолзингер

4

Я признаю, что я фанат ORM и много лет проповедовал преимущества ORM, и мне было что рассказать о том, почему ORM превосходит SQL.

НО...

Я должен признать, что SQL абсолютно необходим в реальном мире, и каждый разработчик должен хорошо понимать SQL.

Процессы SQL работают быстрее, чем ORM, почти во всех случаях. Несмотря на то, что вы можете оптимизировать вывод ORM в большинстве случаев, вы сможете сделать это за секунду до процессов SQL.

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

Просто мои два бита.


4

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

Одна из причин, почему SQL имеет решающее значение для понимания баз данных, заключается в том, что разработчики приложений не думают естественным образом с точки зрения наборов данных. Но единственный эффективный способ работы баз данных - это наборы. Вы должны научиться мыслить в наборах, прежде чем пытаться использовать ORM.


3

Я чаще вручную заставляю запросы в структурах ORM, чем нет. И хотя большинство из них имеют свой собственный язык запросов, все они вдохновлены sql, код превращается в sql, и вам нужно понять, что идет не так, читая этот sql, когда (не если, когда) что-то идет не так или работает плохо.
Поэтому, даже если вы не пишете sql напрямую, понимаете его за пределами базового уровня (хотя вам, вероятно, не нужно узнавать что-то о написании хранимых процедур, триггеров и т. Д., Если все, что вы собираетесь сделать, это получить доступ к базам данных), вы должен знать язык достаточно, чтобы понять сгенерированный код и настроить его по мере необходимости.


3

Прежде чем говорить о вопросе, сначала небольшое введение; Я люблю ОРМ. И я ненавижу SQL. Мне нравятся ORM, потому что они скрывают недружественный пользователю беспорядок, которым является SQL, и обеспечивают хороший интегрированный с языком способ работы с базой данных.

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

С другой стороны, при использовании ORM я настолько поражен простотой интеграции базы данных, что буквально забываю, что есть даже база данных. Это напортачило мне несколько раз. Много раз в прошлом я вызывал невинно выглядящие методы ORM, которые за сценой вызывают массивные и пугающие объединения баз данных, которые снижают производительность.

Вот почему для меня истина где-то посередине. Мне нравится использовать ORM, и я буду продолжать это делать, но я должен быть более осторожным и всегда изучать последствия (на уровне SQL) любого вызова метода ORM. Знание последствий уровня абстракции - чистое золото в этом бизнесе, и оно оправдывает использование абстракции. Все остальное, как выстрел в себя.


3
Я также думаю, что иногда (даже с обычным SQL) люди забывают, что тот факт, что он возвратил набор данных, не означает, что это был правильный набор данных. Я думаю, что с ORM легче забыть, если вы предполагаете, что он сделал все правильно, поскольку вы все равно не понимаете, что он сделал.
HLGEM

Я не согласен с тем, что ORM менее сложен, чем SQL. С SQL вы можете получать данные без программирования. SQL - это не язык программирования, а декларативный, поэтому у него нет структур while, for или if-then.
Тулаинс Кордова

1
Декларативный язык программирования, все еще является языком программирования. SQL - это язык программирования специального назначения, и, по большей части, он декларативный. Что касается сути вашего комментария, я не понимаю. SQL, хотя и не является языком программирования общего назначения, все же остается языком. Вам все еще нужно знать синтаксис, его ограничения и недостатки.
Хараламбос Пасхалидес

2

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


Кому нужно взаимодействовать с базой данных ТОЛЬКО через приложение, которое он / она строит?
Тулаинс Кордова

2

Даже с хорошим, зрелым ORM вы неизбежно столкнетесь с ситуациями, когда он испускает неэффективный SQL и сделает вашу жизнь намного проще, если вы сможете ухватиться за то, что происходит в сгенерированном SQL. Тем не менее, если вы очень хорошо разбираетесь в ORM и знаете, как использовать профилировщик для выбранной вами БД, вы можете довольно легко «подделать ее, пока не сделаете».


1

Ответ на все эти типы вопросов («Нужно ли мне знать Х?») «Выучите его в первый раз, когда он вам понадобится, если он вам когда-нибудь понадобится».

Тем не менее, важно не попадать в ловушку, когда вы делаете вещи менее эффективно, потому что вы не знаете или не хотите учиться эффективному способу их выполнения.

В данном конкретном случае, например, что вы будете делать, если поймете, что в вашей программе была ошибка, из-за которой PostCountполе вашей пользовательской таблицы иногда было неточным.

Вы исправили ошибку и теперь вам нужно обновить PostCount для всех пользователей. Как ты делаешь это?

Если вы пишете небольшой скрипт, используя ORM для этого, то вы очень неэффективны; очень простой SQL-запрос.

Поскольку эти ситуации довольно распространены, я боюсь, что вы попали в ловушку, описанную выше!


2
Я согласен: если вы не знаете SQL, вы часто пишете десятки строк кода, чтобы сделать то, что вы могли бы сделать с помощью одного SQL-запроса.
Бензадо

2
«изучите это в первый раз, когда вам это нужно»: ro-che.info/ccc/11.html
MatrixFrog

1

Да, вам все еще нужен SQL.

Не спешите с предположением, что что-то «старое» как-то недостойно рассмотрения. Так называемые «устаревшие» технологии - это те, которые все еще существуют после того, как прошли испытание временем. Мы не называем компьютеры Wang «наследием», они потерпели неудачу и ушли.

Если вы спросите меня, беспокоит ли меня, что мой банк, вероятно, использует COBOL на мэйнфрейме или IBM i? Абсолютли нет. Это надежные и проверенные технологии. Угадайте, что они в основном используют DB2 SQL. Я гораздо больше доверяю своим деньгам, чем программам, разработанным на модном языке месяца.

Динозавры существовали на этой земле гораздо дольше, чем мы, люди. И если вы читаете «Парк Юрского периода» (да, книги лучше, чем фильмы), то я спрашиваю вас: действительно ли вы хотите встретить группу сверхчувственных велоцирапторов или упрямого Т-Рекса, который никогда не сдается? Не укушайте, недооценивая «динозавров». ;-)


0

Помимо игр и (в основном, статистических) исследований, с которыми у меня нет опыта, кажется, что доступ к базам данных и операции - одна из немногих областей, где неправильные решения приводят к очень большому падению производительности. Я твердо верю в более мощные абстракции базы данных в коде, и я верю в linq, который связывает операции базы данных с языком программирования, предоставляя вам все инструменты языка (проверка типов, проверка синтаксиса, все, что вам нравится) ваш язык программирования), в то же время давая вам достаточно сил, чтобы делать то, что вы хотите, абсолютно потрясающе. К сожалению, это все еще не всегда работает. Это означает, что если уровень абстракции дает неверные результаты оптимизации, и вы, возможно, будете ждать секунд вместо микросекунд или минут вместо секунд для вашего результата. Так как это очень заметные времена, Вы должны оптимизировать их, иначе ваше приложение не «работает»: производительность становится самой большой проблемой вашего приложения. Это означает, что вам нужно приблизиться к металлу и оптимизировать руки.

Когда мы дойдем до того, что манипулирование большими наборами данных занимает, например, 3 мс при ручном выполнении, и 100 мс, когда вы позволяете уровню абстракции делать это за вас, непременно, пусть уровень абстракции обрабатывает это за вас, потому что вы можете быть в 30 раз медленнее, но вы все еще (вероятно, для большинства приложений) достаточно быстро. Однако реальность ситуации такова, что когда вы смотрите на оптимизированные решения, где у вас есть время отклика 200 мс, и когда уровень абстракции обрабатывает его для вас, алгоритм «просто» достигает 10-кратного успеха, у вас есть Задержка в 2 секунды, а потом вас все волнует, от не слишком быстрого до мучительно медленного. Видя, что решения для реляционных баз данных плохо масштабируютсяЯ не думаю, что это будет решено через два или три года. Это означает, что вам все равно придется довольно долго опускаться до чистого металла, когда дело доходит до более крупных баз данных, иначе ваше приложение будет слишком медленным, оно не сможет противостоять конкурентам.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.