учить - как работать с sql




Почему нет любви к SQL? (20)

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

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

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


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

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

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

... причина, о которой я только что описал выше.

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

Адрес реляционной базы данных Сильная согласованность и разделение-терпимость.

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

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


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

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

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

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


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

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


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

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

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

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

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

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

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

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


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

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

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


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

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


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

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

Для других причины таковы:

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

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

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


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

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


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

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

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


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

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


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

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

SQL замечательный. Слои абстракции над ним делают его еще более значительным!


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

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


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

  • он пытается одновременно быть высоким уровнем и абстракцией низкого уровня , и это ... странно. Возможно, это должны были быть два или более стандартов на разных уровнях.
  • это огромный провал в качестве стандарта . Многие вещи идут вразрез с тем, что стандарт либо движется во всём, либо требует слишком много реализаций, либо слишком мало, либо по какой-то причине не выполняет частично социальную цель, побуждающую продавцов и разработчиков создавать строго соответствующие совместимые полные реализации. Вы, конечно же, не можете сказать, что SQL это сделал. Посмотрите на некоторые другие стандарты и обратите внимание, что успех или неудача стандарта явно является фактором полезного сотрудничества:
    • RS-232 ( Плохое , не достаточно точное, даже то, что штырь передает и какой штырь получает, является необязательным, sheesh. Вы можете выполнить, но ничего не достигли. Шанс успешного взаимодействия: действительно низкий, пока IBM PC не станет де-факто полезным стандартом .)
    • IEEE 754-1985 Floating Point ( Bad , overreach: not a single supercomputer or scientific workstation or RISC microprocessor ever adopted it, although eventually after 20 years we were able to implement it nicely in HW. At least the world eventually grew into it.)
    • C89, C99, PCI, USB, Java ( Good , whether standard or spec, they succeeded in motivating strict compliance from almost everyone, and that compliance resulted in successful interoperation.)
  • it failed to be selected for arguably the most important database in the world . While this is more of a datapoint than a reason, the fact that Google Bigtable is not SQL and not relational is kind of an anti-achievement for SQL.

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


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

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

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

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


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

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

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

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


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

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


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





frameworks