Почему нет любви к SQL? [закрыто]

116

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

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

Что делает SQL таким ужасным и почему так ценны уровни абстракции базы данных?

Трэвис
источник
11
как насчет безопасности типов?
Джонни,
3
На кого в точности нацелены эти уровни абстракции? SQL - это не тот язык, на котором все хороши, поэтому они могут быть нацелены на посредственных программистов. Сам по себе SQL совсем не хороший язык для непрограммиста.
Дэвид Торнли,
27
@ Дэвид: Определите (компьютерный) язык, который «хорош для непрограммиста». Непрограммисты, IMHO, должны держаться подальше от языков программирования (и в более широком смысле этого слова, SQL).
DevSolar,
15
все ответы тоже должны быть вики. просто безумие, что подобные вопросы и ответы набирают столько голосов. Я думал, это технический форум? вы можете решить чью-то проблему, предоставив сложный для написания код и получив одно или два голоса за, но ответив на такой вопрос и получив множество голосов за. это действительно отстой, если вы спросите меня.
КМ.
6
@KM: Проблема с голосами в том, что они во многом зависят от количества людей, читающих ответ. Я ответил на многие вопросы NHibernate и Rhino Mocks, на которые потребовалось некоторое время, чтобы правильно ответить - и был принят, но ни разу не проголосовал. Если вы ответите на какой-нибудь тривиальный вопрос о C #, вы получите десятки голосов. Голоса просто нечестные. Предложите что-нибудь на meta.stckoverflow, если знаете что-нибудь получше.
Стефан Штайнеггер

Ответы:

132

Отчасти это субъективно. Так что это мое мнение:

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

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

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

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

Но это правда - реальных альтернатив нет. Так что все мы будем использовать SQL в ближайшие несколько лет.

Стефан Штайнеггер
источник
31
«Просто укажите, что вы хотите - доставим в кратчайшие сроки». Этот декларативный подход фантастичен и на самом деле современен (подумайте о LINQ). Это правда, что иногда вам нужно настроить скорость, и тогда может оказаться полезной процедурная альтернатива SQL. Но для простоты я бы все еще большую часть времени использовал декларативный SQL.
MarkJ
4
MarkJ: Я помню, что я переупорядочил предложения WHERE, чтобы оптимизировать запросы в oracle. Они были решены снизу доверху ... ужасно.
Стефан Штайнеггер,
16
Я полностью согласен. ИТ-специалисты очарованы непроцедурными инструментами. Разве не было бы намного проще, если бы вы просто сказали компьютеру, что вы хотите, и он выяснил, как это сделать! Да, если бы компьютер действительно был достаточно умен для этого. Но это не так. Я бы хотел, чтобы я просто сказал своей машине: «Отвези меня к бабушке», и она отвезет меня туда. Но это не так, поэтому я не отпускаю руль и не делаю вид, что это сработает. Может быть, когда-нибудь технологии появятся, а может быть, это несбыточная мечта. Но сегодня его нет. (продолжение ...)
Джей,
12
Туш. Ваш ответ прекрасно описывает мои ранние разочарования в SQL. Я написал много процедурного кода, потому что я не доверял SQL в создании эффективного плана выполнения. По мере того, как я становился более осведомленным в SQL, я обнаружил, что он на самом деле неплохо подходит для оптимизации и что правильно написанный SQL обычно работает быстрее, чем мой процедурный код.
Kluge
5
@Jay и другие сомневающиеся в SQL. По моему опыту, проблема заключается в том, что для эффективного использования SQL вы должны уметь мыслить в терминах множеств, а не процедурно - именно так большинство программистов учат думать. Эффективное использование SQL на самом деле не так сложно и доступно любому компетентному программисту (как любой, кто читает SO!), Но необходимо приложить усилия, чтобы перейти к мышлению в логике, основанной на множествах, и большую часть времени люди не делают этого. не беспокойтесь (и в настоящее время я изменяю программу, в которой исходный кодировщик делал все с использованием курсоров именно по этой причине)
Cruachan
58

Помимо всего, что было сказано, технология не должна быть плохой, чтобы сделать уровень абстракции ценным .

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

SQL великолепен. Слои абстракции над ним делают его еще больше!

Мигель Вентура
источник
6
Очень дипломатично! (И правда, в придачу!)
Джозеф Феррис,
2
Проблема в инверсии абстракции. SQL в реляционной базе данных - это декларативная среда на основе наборов. Он имеет более высокий уровень абстракции, чем императивное программирование, объектно-ориентированное или нет.
Стивен Хьювиг,
2
Может быть, Стивен, но с точки зрения приложения он выполняет функцию низкого уровня (даже если выполняет это чрезвычайно высоким способом). Независимо от того, какие сумасшедшие преобразования вы делаете на уровне базы данных, в конце концов, это прославленный геттер и сеттер. Или вы можете посмотреть на это с другой стороны, так как это слишком высокий уровень, чтобы смешивать его с приложением, и его необходимо изолировать и рассматривать отдельно. В любом случае сохранение SQL вне основного кода приложения дает очень ощутимые преимущества с точки зрения читаемости и рефакторинга.
Дата выпуска
53

Одним из аспектов уровней абстракции является тот факт, что реализации SQL имеют тенденцию быть более или менее несовместимыми друг с другом, поскольку стандарт немного неоднозначен, а также потому, что большинство поставщиков добавили туда свои собственные (нестандартные) дополнения. То есть SQL, написанный для БД MySQL, может не работать так же, как, скажем, с БД Oracle - даже если «должен».

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

Йоонас Пулакка
источник
19
Я не понимаю, как несовместимость диалектов SQL может быть такой большой «точкой» против SQL. Это все равно, что сказать, что C - чушь, потому что вы не можете просто скомпилировать + запустить один и тот же исходный код в разных дистрибутивах Linux. Если ваша компания решит сменить поставщика баз данных, и это большая IF, это редкий и крупный случай, когда есть больше движущихся частей, чем просто переписывание некоторого SQL.
Джефф Фрикаделька Ян,
7
Это не точка против SQL, это точка зрения на уровни абстракции. Например, вы не можете просто скомпилировать + запустить один и тот же код C где угодно, это точка для большего количества языков, не зависящих от платформы. Но это не делает SQL или C «дерьмом»: в любом случае уровни абстракции работают поверх более глубоких слоев.
Joonas Pulakka
8
@Jeff: В C общие задачи являются частью стандарта. В SQL невозможно разбить набор результатов на страницы, не обращаясь к SQL, зависящему от поставщика.
Powerlord,
4
Да, и про редкость смены поставщиков баз данных: о чем вы? Делает ли редкость смены операционных систем компанией кроссплатформенные решения неактуальными? Вы не всегда знаете заранее, на чем будет работать ваш продукт, поэтому лучше ошибиться в пользу более общих решений.
Joonas Pulakka
3
@Joonas: Думаю, я хотел сказать, что язык (и) SQL не является проблемой. Был задан вопрос, что делает SQL таким ужасным, и моя первая реакция, как и ваша, заключается в том, что это не так. Но я хотел возразить, что приспособление к различным диалектам на самом деле не является сутью ORM - они были бы у нас, даже если бы у нас был только один стандартный язык - я думаю, что нам нужен способ преобразования нормализованных данных в объектно-ориентированную модель.
Джефф Фрикаделька Ян,
36

SQL критикуют из нескольких источников:

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

Если вы придерживаетесь одного продукта СУБД, то я определенно согласен с тем, что СУБД SQL более универсальны и более качественны, чем их конкуренты, по крайней мере, до тех пор, пока вы не столкнетесь с барьером масштабируемости, присущим модели. Но действительно ли вы пытаетесь написать следующий Твиттер или просто хотите, чтобы некоторые бухгалтерские данные были организованы и согласованы?

Критика SQL часто заменяет критику СУБД. Критики СУБД, похоже, не понимают того, что они довольно хорошо решают огромный класс вычислительных задач и что они здесь, чтобы облегчить нам жизнь, а не усложнить ее.

Если бы они серьезно относились к критике самого SQL, они бы поддержали такие усилия, как Tutorial D и Dataphor.

Стивен Хьювиг
источник
7
Что касается первого пункта о том, что программистам неудобно работать только с императивным языком. В ближайшие несколько лет будет интересно посмотреть, имеет ли / как возрождение функционального программирования какое-либо значение для этого. Сейчас много шумихи вокруг таких языков, как Haskell, F # и Scala, которые делают разработчиков намного более продуктивными. Этот тип «математического» мышления для программистов очень похож на знание реляционной алгебры и реляционного исчисления кортежей, которое предполагает SQL. Может быть, со временем произойдет возрождение нативного мышления, основанного на наборах SQL!
Тревор Типпинс,
Я должен пояснить, что я имел в виду «этих программистов, которым не комфортно ничего, кроме императивного программирования», а не то, что всем программистам это неудобно.
Стивен Хьювиг,
+1, хорошо сказано. И как человек, который первые несколько лет проработал там профессиональным программистом в реляционной базе данных, я нахожу откровенно ошеломляющим то, что кто-то хочет вернуться в ту эпоху, за исключением специализированных задач. Дня, потраченного на написание кода, пересекающего древовидную структуру DL / 1, должно быть достаточно, чтобы кого-то убедить.
Cruachan,
Проблема в том, что есть много навязчивых программистов, которые предпочли бы набросать несколько сотен строк безвкусного кода, чем думать о вещах час или около того.
Стивен Хьювиг, 08
Вам не нужно думать о вещах в течение часа, чтобы написать или понять несколько строк кода. Период.
Эндрю
23

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

Тревор Типпинс
источник
16

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

Фактическое ИСПОЛЬЗОВАНИЕ SQL может быть ТАК затронутым дизайном базовой базы данных, что SQL может не быть проблемой, но дизайн может - и когда вы добавляете унаследованный код, связанный с плохим дизайном, изменения становятся более опасными и дорогостоящими для внедрения ( никто не любит возвращаться и «исправлять» вещи, которые «работают» и соответствуют целям)

Плотники могут забивать гвозди молотком, распиливать пиломатериалы и гладить доски рубанком. Можно «пилить» молотком и рубанком, но, черт возьми, это неприятно.

Марк Шультайс
источник
11

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

SQL был разработан для реляционной алгебры - вот где его следует использовать.

Николай Р
источник
2
К сожалению, очень соблазнительно просто вставить какой-нибудь простой процедурный код в хранимую процедуру. И работает нормально. ДО тех пор, пока кому-то не понадобится поддерживать это / добавлять исключения и т. Д.
Брайан Ноблауч,
5
-1, эээ в том-то и дело, SQL спроектирован так, чтобы быть установленным, и в этом его сила. Процедурное мышление означает, что вы думаете неправильно.
Круачан,
1
Эта отвертка - отстой! Им так сложно забить ногти.
Кейси Родармор
9

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

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

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

… Причина, которую я описал выше.

Слои базы данных ничего не добавляют , они просто ограничивают вас. Они делают запросы намного проще, но никогда не более эффективными.

По определению, в слоях базы данных нет ничего, чего бы не было SQL.

Что в этом SQLтакого ужасного и почему так ценны уровни абстракции базы данных?

SQL - хороший язык, однако, чтобы работать с ним, нужно немного потрудиться.

Теоретически SQLэто декларативно, то есть вы объявляете, что хотите получить, а движок предоставляет это максимально быстро.

На практике существует множество способов сформулировать правильный запрос (то есть запрос, возвращающий правильные результаты).

Оптимизаторы могут построить замок Lego из некоторых предопределенных алгоритмов (да, их несколько), но они просто не могут создавать новые алгоритмы. По-прежнему требуется SQLпомощь разработчика.

Однако некоторые люди ожидают, что оптимизатор выдаст «наилучший возможный план», а не «лучший план, доступный для этого запроса с данной реализацией SQLмеханизма».

И, как все мы знаем, когда компьютерная программа не оправдывает ожиданий людей, винят именно программу, а не ожидания.

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

Однако было бы неплохо, если бы поставщики предоставили некоторый низкоуровневый доступ к функциям, таким как «получить диапазон индекса», «получить строку по rowid» и т. Д., Например, Cкомпиляторы позволят вам встроить сборку прямо в язык.

Недавно я написал об этом статью в своем блоге:

Quassnoi
источник
7

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

Я смотрю на SQL как на сверхэффективный язык, который не имеет в качестве приоритетов повторное использование кода или ремонтопригодность / рефакторинг.

Таким образом, приоритетом является молниеносная обработка. И это приемлемо. Вам просто нужно знать о компромиссах, которые для меня значительны.

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

Брайан Маккей
источник
7

Я бы сказал, что уровень абстракции базы данных, включенный в фреймворк, - это хорошо, потому что он решает две очень важные проблемы:

  1. Он сохраняет код отличным. Помещая SQL на другой уровень, который обычно очень тонкий и должен выполнять только основы запросов и передачи результатов (стандартизованным способом), вы избавляете свое приложение от беспорядка SQL. По той же причине веб-разработчики (должны) помещать CSS и Javascript в отдельные файлы. Если вы можете этого избежать, не смешивайте свои языки .

  2. Многие программисты просто плохо используют SQL. По какой-то причине большое количество разработчиков (особенно веб-разработчиков) кажутся очень и очень плохими в использовании SQL или СУБД в целом. Они относятся к базе данных (и к SQL по расширению) как к маленькому грязному посреднику, через которого им приходится обращаться к данным. Это приводит к чрезвычайно плохо продуманным базам данных без индексов, таблицам, сложенным поверх таблиц сомнительным образом, и очень плохо написанным запросам. Или, что еще хуже, они пытаются быть слишком общими (Экспертная система, кто-нибудь?) И не могут разумно связать данные каким-либо значимым образом.

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

Dereleased
источник
6

SQL отлично подходит для определенных видов задач, особенно для манипулирования наборами данных и их получения .

Однако в SQL отсутствуют (или реализованы лишь частично) несколько важных инструментов для управления изменениями и сложностью:

  • Инкапсуляция : механизмы инкапсуляции SQL грубые. Когда вы пишете код SQL, вы должны знать все о реализации ваших данных. Это ограничивает степень абстракции, которую вы можете достичь.

  • Полиморфизм : если вы хотите выполнить одну и ту же операцию с разными таблицами, вам нужно написать код дважды. (Можно смягчить это с помощью творческого использования представлений.)

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

  • Модульность и управление версиями

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

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

Джефф Стернал
источник
А как насчет схем для управления видимостью?
Трехзначная логика
5

SQL основан на теории множеств, тогда как большинство языков высокого уровня сегодня объектно-ориентированы. Программисты, работающие с объектами, обычно любят мыслить объектами, и им приходится совершать мысленный сдвиг, чтобы использовать инструменты на основе Set для хранения своих объектов. Как правило, гораздо естественнее (для объектно-ориентированного программиста) просто вырезать код на языке по своему выбору и делать что-то вроде object.save или object.delete в коде приложения вместо того, чтобы писать sql-запросы и вызывать базу данных для достижения тот же результат.

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

Питер Бейли
источник
5

ИМО, проблема, которую я вижу у людей с SQL, не имеет ничего общего ни с реляционным дизайном, ни с самим языком SQL. Это связано с дисциплиной моделирования уровня данных, которая во многих отношениях фундаментально отличается от моделирования бизнес-уровня или интерфейса. Ошибки при моделировании на уровне представления, как правило, гораздо легче исправить, чем на уровне данных, где у вас есть несколько приложений, использующих базу данных. Эти проблемы те же, что и при моделировании уровня сервиса в проектах SOA, где вы должны учитывать текущих потребителей вашего сервиса и контракты ввода и вывода.

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

Томас
источник
4

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

tvanfosson
источник
2
Верно, но для этого вам не нужен ORM
finnw
2
Использование параметризованных запросов тривиально при написании SQL напрямую, при условии, что у вас есть достойный уровень интерфейса базы данных (т. Е. Тот, который поддерживает заполнители). $dbh->do("DELETE FROM my_table WHERE some_value = ?", undef, $target_value); Там. Готово.
Дэйв Шерохман,
Я никогда не говорил, что нельзя писать параметризованные запросы с помощью RAW SQL. Я сказал, что использование необработанного SQL более рискованно, поскольку вы должны реализовать его самостоятельно. Я видел много случаев необработанного кода SQL, когда запрос не параметризован. ORM предоставляют это преимущество автоматически.
tvanfosson
2
Верно, но избежать SQL-инъекций тривиально просто даже без подготовленных операторов. В каждом проекте, который я делаю, я пишу простую функцию, которая помещает строку в кавычки и правильно избегает любых встроенных кавычек. На написание уходит минут пятнадцать, даже если я не копирую его из предыдущего проекта. Затем я использую это для каждого литерала, встраиваемого в запрос. Меня ошеломляет то, что программисты этого не делают! Не занимайте пятнадцать минут, чтобы избежать преднамеренной или, что чаще встречается, случайной SQL-инъекции! Почему нет?!
Джей,
3
Джей, учитывает ли эта «простая функция, которая помещает строку в кавычки и правильно экранирует любые встроенные кавычки» текущий набор символов, используемый на сервере?
ygrek
4

Много слышал в последнее время? Надеюсь, вы не путаете это с движением NoSql. Насколько мне известно, это в основном группа людей, которые используют NoSql для веб-приложений с высокой масштабируемостью и, кажется, забыли, что SQL - это эффективный инструмент в сценарии «веб-приложения с высокой масштабируемостью».

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

Quibblesome
источник
4

Для опытного программиста SQL плохие стороны:

  • многословие
  • Как здесь многие говорили, SQL является декларативным, что означает, что оптимизация не является прямой . Это как ралли по сравнению с кольцевыми гонками.
  • Фреймворки, которые пытаются адресовать все возможные диалекты и не поддерживают ярлыки ни на одном из них
  • Нет простого контроля версий.

Для других причины в том, что

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

Основная цель сред SQL - сократить объем набора текста. Каким-то образом они работают, но слишком часто только для очень простых запросов. Если вы пытаетесь сделать что-то сложное, вам придется использовать строки и много печатать. Фреймворки, которые пытаются обрабатывать все возможное, такие как SQL Alchemy, становятся слишком огромными, как другой язык программирования.

[обновление от 26.06.10] Недавно я работал с модулем Django ORM . Это единственная достойная среда SQL, которую я видел. И этот заставляет много работать с разными вещами. Однако сложные агрегаты немного сложнее.

culebrón
источник
3

SQL - не ужасный язык, просто иногда он не очень хорошо работает с другими.

Если, например, у вас есть система, которая хочет представить все сущности как объекты на каком-либо объектно-ориентированном языке, то объединение этого с SQL без какого-либо уровня абстракции может стать довольно громоздким. Нет простого способа отобразить сложный SQL-запрос в объектно-ориентированный мир. Чтобы ослабить напряжение между этими мирами, добавляются дополнительные уровни абстракции (например, OR-Mapper).

Иоахим Зауэр
источник
Почему SQL виноват в том, что объектно-ориентированные языки не соответствуют ему? Когда вы используете сервис, соблюдайте его интерфейс или не используйте его.
КМ.
2
Никто не сказал, что это ошибка SQL. Языковым языком доступа к БД является SQL. Язык бизнес-логики - это объектно-ориентированный язык. Эти двое не подходят идеально без посторонней помощи. Здесь нет «неисправности» или «проблемы», только некоторые требования («приведите их в соответствие») и общепринятое решение («используйте OR-Mapper»).
Иоахим Зауэр,
Йоахим Зауэр сказал, что SQL - это не ужасный язык, он просто не слишком хорошо работает с другими. Для меня это звучит так, будто кто-то сказал, что это ошибка SQL
KM.
1
@KM: Вы хотите сказать, что французский и немецкий - плохие языки? Они не очень хорошо владеют английским.
Дэвид Торнли,
3

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

Другая причина, по которой ненавидят SQL, - это реляционные базы данных.

Теорема CAP становится популярной:

Какие цели вы можете желать от системы с общими данными?

  • Сильная согласованность: все клиенты видят одно и то же представление, даже при наличии обновлений
  • Высокая доступность: все клиенты могут найти какую-то копию данных даже при наличии сбоев.
  • Стойкость к разделению: свойства системы сохраняются, даже когда система разделена

Теорема утверждает, что вы всегда можете иметь только два из трех свойств CAP одновременно.

Адрес реляционной базы данных: Strong Consistency and Partition-Tolerance.

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

Если реляционная база данных отклонена, SQL также отклоняется.

Николя Дорье
источник
3

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

Моя теория состоит в том, что SQL был изобретен кучкой синих лыжников из слоновой кости. Вся непроцедурная структура. Звучит здорово: скажите мне, чего вы хотите, а не как вы хотите это сделать. Но на практике часто проще просто указать шаги. Часто это похоже на попытку дать инструкции по уходу за автомобилем, описав, как он должен работать, когда вы закончите. Да, вы могли бы сказать: «Я хочу, чтобы машина снова набирала 30 миль на галлон и ехала с таким жужжащим звуком ... хммм ... и т. Д.» Но разве не было бы проще для всех просто сказать «Замени свечи зажигания»? И даже когда вы понимаете, как выразить сложный запрос в непроцедурных терминах, ядро ​​базы данных часто предлагает очень неэффективный план выполнения, чтобы добраться до него.

И обработка нулей сводит меня с ума! Да, теоретически это должно было звучать великолепно, когда кто-то сказал: «Эй, если ноль означает неизвестное, то добавление неизвестного значения к известному значению должно дать неизвестное значение. В конце концов, по определению мы понятия не имеем, что такое неизвестное значение. «. Теоретически абсолютно верно. На практике, если у нас 10 000 клиентов, и мы точно знаем, сколько денег нам должны 9 999, но есть некоторый вопрос о сумме задолженности последнего, и руководство говорит: «Какова наша общая дебиторская задолженность?», Да, математически верно ответ - «не знаю». Но практический ответ таков: «мы рассчитываем 4 327 287,42 доллара, но под вопросом один аккаунт, поэтому это число неточно». Я уверен, что менеджмент скорее предпочел бы приблизиться, если не определенное число, чем пустой взгляд.

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

сойка
источник
3
Вся идея реляционной базы данных была продуктом голубых любителей башни из слоновой кости. Ранние реляционные базы данных обладали ужасной производительностью по сравнению с нынешними иерархическими базами данных, и требовалось много времени для создания. Сила абстракции была такова, что иерархические базы данных, по сути, ушли в прошлое (не то чтобы баз данных IMS и CODASYL все еще не существовало). Это должно было сработать очень и очень хорошо.
Дэвид Торнли,
1
Но руководство не увидело бы «близкое, если бы не определенное число» - они увидели бы неправильное число. Возможно, этот конечный покупатель должен много денег. Тогда руководство было бы очень недовольно ошибочным номером.
HTTP 410,
RoadWarrior: Да, возможно, у вас есть 10 000 клиентов, каждый из которых должен вам 10 долларов, и 1 клиент, который должен вам 10 миллионов долларов. Но если бы это было так, любой, кто запрашивал отчет AR, вероятно, очень хорошо знал бы имя этого клиента и точно знал, что с ним происходит. Ладно, я уверен, что бывают случаи, когда лучше вообще отсутствие ответа, чем ответ, который настолько ненадежен, что теряет смысл. Но это моя точка зрения: SQL разработан на основе таких теоретических соображений: догматическое «все, что меньше совершенства, ничего не стоит». ...
Джей
... В реальной жизни в 95% случаев приблизительный ответ намного лучше, чем пустой взгляд. Когда я смотрю в свою чековую книжку, я понимаю, что вполне возможно, что я сделал арифметическую ошибку или забыл написать чек. Баланс вполне может быть приблизительным. Но все же, если я буду знать, что у меня «около 1000 долларов», я без колебаний выпишу чек на 50 долларов и пойму, что выписывать чек на 10 000 долларов будет бесполезно.
Джей
Что ж, у меня есть бизнес, и это никогда не 10 КБ против 1. IMX, это больше похоже на 20 неизвестных на каждые 100 известных (принцип Парето). И некоторые из этих 20 были должны нам много денег, поэтому фактическая сумма и была предметом спора. Опять же, это принцип Парето.
HTTP 410
3

• Каждый поставщик расширяет синтаксис SQL в соответствии со своими потребностями. Поэтому, если вы не делаете довольно простые вещи, ваш код SQL не переносится.

• Синтаксис SQL не ортогонален; например, все операторы select, insert, update,и deleteимеют совершенно разную синтаксическую структуру.

Дэвид Р. Триббл
источник
1
Как это делает синтаксис не ортогональным?
Amok,
1
Язык может быть быть сконструирован таким образом, что все эти императивные утверждения имеют более общий синтаксис, особенно между insertи updateоперациями, которые почти идентичны семантический, но совершенно разными синтаксический.
Дэвид Р. Триббл,
2

Я согласен с вашими замечаниями, но отвечу на ваш вопрос: одна вещь, которая делает SQL таким «ужасным», - это отсутствие полной стандартизации T-SQL между поставщиками баз данных (Sql Server, Oracle и т. Д.), Что делает код SQL маловероятным. полностью портативный. Уровни абстракции базы данных решают эту проблему, хотя и со снижением производительности (иногда очень серьезным).

MusiGenesis
источник
2
Я не понимаю, как несовместимость диалектов SQL может быть такой большой «точкой» против SQL. Это все равно, что сказать, что C - чушь, потому что нельзя просто скомпилировать + запустить один и тот же исходный код в разных дистрибутивах Linux.
Джефф Фрикаделька Ян,
1
@Jeff: На самом деле, я не думаю, что это большой аргумент против SQL. Вот почему я сказал: «Я согласен с вашими соображениями» и заключил в кавычки «ужасно». Лично я предпочитаю SQL слоям абстракции данных, хотя я рад, что существуют такие вещи, как NHibernate, потому что они намного лучше, чем домашняя чушь, которая раньше разрасталась.
MusiGenesis
1
Верно - я тоже использую уровни абстракции - думаю, я хотел сказать, что для меня проблема не в языке SQL, а в преобразовании нормализованных данных в объекты, поэтому слои абстракции полезны.
Джефф Фрикаделька Ян,
2

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

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

ovolko
источник
Работа с экземплярами объектов в памяти сильно отличается от данных, которые физически хранятся в базе данных. есть больше проблем с исправлением плохого дизайна и, возможно, огромные вариации в производительности, основанные на «мелочах»
KM.
2

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

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

Джефф Фрикаделька Ян
источник
2

Быстро, напишите мне SQL, чтобы разбить на страницы набор данных, который работает в MySQL, Oracle, MSSQL, PostgreSQL и DB2.

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

Powerlord
источник
5
Почему вы пытаетесь нацелить свой код на все эти среды? Напишите мне код C для потоков, который работает в Mac OS 9, Windows NT, OS / 2 Warp и Solaris.
Стивен Хьювиг,
2
@Steven Huwig: Я бы, наверное, использовал слой абстракции, чтобы сделать это за меня ... именно это и задавался вопросом.
Powerlord
@Steven: Я действительно использую фреймворки и слои абстракции для довольно многих вещей, где мне нужно быть независимым от платформы. Однако в большинстве случаев независимость от базы данных гораздо важнее. Даже если вы поставляете свое программное обеспечение только для работы в Windows, как только вы начнете продавать его более крупным корпорациям, вы столкнетесь со всем: от «Мы предпочитаем OSS, поддерживаете ли вы MySQL» до «Мы используем Oracle | MSSQL | корпоративный стандарт, вы его поддерживаете ».
Фредрик
2

Нет любви к SQL, потому что SQL плох в синтаксисе, семантике и текущем использовании. Я объясню:

  • его синтаксис - шрапнель кобола, здесь применима вся критика кобола (в меньшей степени, если честно). Попытка быть естественным языком, например, без фактической попытки интерпретировать естественный язык, создает произвольный синтаксис (это DROP TABLE или DROP, UPDATE TABLE, UPDATE или UPDATE IN, DELETE или DELETE FROM ...) и синтаксические чудовища, такие как SELECT (сколько страниц делает это заполнить?)
  • семантика также глубоко ошибочна, Дейт объясняет это очень подробно, но будет достаточно отметить, что трехзначная логическая логика на самом деле не подходит для реляционной алгебры, где строка может быть только или не быть частью таблицы.
  • использование языка программирования в качестве основного (и часто единственного) интерфейса для баз данных оказалось действительно плохим выбором, и это создало новую категорию недостатков безопасности
stupito
источник
1

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

Декларативные языки, как указал Стефан Штайнеггер, хороши для указания того, что вы хотите, а не того, как вы хотите это делать. Это означает, что ваши различные реализации SQL достойны с точки зрения высокого уровня: то есть, если все, что вам нужно, это получить некоторые данные, и все остальное не имеет значения, вы можете удовлетворить себя написанием относительно простых запросов и выбором реализации SQL. это подходит вам.

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

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

NateDSaint
источник
Вы можете избавить себя от этой боли, просто не используя MySQL. ;)
Стивен Хьювиг
1

Хотя SQL действительно выполняет свою работу, у него, безусловно, есть проблемы ...


  • он пытается одновременно быть абстракцией высокого и низкого уровня , и это ... странно. Возможно, это должны были быть два или более стандартов на разных уровнях.
  • это огромный провал как стандарт . Многие вещи идут не так, как надо, когда стандарт либо мешает во всем, требует слишком много от реализаций, просит слишком мало, либо по какой-то причине не выполняет частично социальную цель мотивации поставщиков и разработчиков к созданию строго соответствующих совместимых полных реализаций. Вы, конечно, не можете сказать, что SQL сделал что-либо из этого. Посмотрите на некоторые другие стандарты и обратите внимание, что успех или неудача стандарта явно являются фактором достигнутого полезного сотрудничества:
    • RS-232 ( Плохо , недостаточно точно определено, даже какой вывод передает, а какой вывод принимает, необязательно, черт возьми. Вы можете соблюдать, но все равно ничего не добьетесь. Шансы на успешное взаимодействие: очень низки, пока IBM PC не сделает де-факто полезный стандарт .)
    • IEEE 754-1985 с плавающей точкой ( плохое , чрезмерно: ни один суперкомпьютер, научная рабочая станция или микропроцессор RISC никогда не принимал его, хотя в конце концов, через 20 лет, мы смогли хорошо реализовать его в HW. По крайней мере, мир в конечном итоге превратился в него.)
    • C89, C99, PCI, USB, Java ( хорошо , будь то стандарт или спецификация, им удалось добиться строгого соблюдения почти всеми, и это соблюдение привело к успешному взаимодействию.)
  • она не попала, пожалуй, в самую важную базу данных в мире . Хотя это скорее источник данных, чем причина, тот факт, что Google Bigtable не является SQL и не является реляционным, является своего рода анти-достижением для SQL.
DigitalRoss
источник
0

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

Однако преимущества огромны. Написание собственных тестов для кода с использованием выразительных классов, строго типизированных наборов данных и т. Д. Мы используем своего рода «DAL», который является чистой реализацией DDD с использованием Generics в C #. Итак, у нас есть общие репозитории, реализации единиц работы (транзакции на основе кода) и логическое разделение. Мы можем делать такие вещи, как макеты наших наборов данных с небольшими усилиями и фактически развиваться, опережая реализации баз данных. Создание такой структуры потребовало предоплаты, но очень приятно, что бизнес-логика снова стала звездой шоу., Сейчас мы потребляем данные как ресурс и обрабатываем их на языке, который мы изначально используем в коде. Дополнительным преимуществом этого подхода является обеспечиваемое им четкое разделение. Например, я больше не вижу запроса к базе данных на веб-странице. Да, этой странице нужны данные. Да, база данных задействована. Но теперь, независимо от того, откуда я беру данные, есть одно (и только одно) место, где можно войти в код и найти его. Возможно, это не имеет большого значения для небольших проектов, но когда у вас есть сотни страниц на сайте или десятки окон в настольном приложении, вы действительно можете это оценить.

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

Джозеф Феррис
источник
1
Голосующий против - хотите объяснить, почему, или просто нажимаете кнопку вниз для всего, с чем не согласны?
Джозеф Феррис,
0

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

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

Adriaan
источник