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

Ответ 1

Это отчасти субъективно. Итак, это мое мнение:

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

SQL получает неудачу из нескольких источников:

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

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

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

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Двойное мышление в SQL

Ответ 9

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

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

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

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

Ответ 10

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

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

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

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

Ответ 11

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

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

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

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

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

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

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

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

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

Ответ 15

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

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

Для других причина заключается в том, что

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

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

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

Ответ 16

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

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

Ответ 17

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

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

Ответ 18

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

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

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

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

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

В теореме говорится, что вы всегда можете имеют только два из трех CAP свойства в то же время

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

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

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

Ответ 19

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

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

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

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

Ответ 20

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

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

Ответ 21

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

Ответ 22

Жизнь с чистым SQL действительно может быть адским обслуживанием. Для меня самым большим преимуществом ORM является способность безопасно реорганизовать код без утомительных процедур рефакторинга "DB". Есть хорошие рамки модульного тестирования и инструменты рефакторинга для языков OO, но я все же должен видеть, например, экземпляр Resharper для SQL.

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

Ответ 23

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

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

Ответ 24

Скорее, напишите мне SQL для разбивки набора данных, который работает в MySQL, Oracle, MSSQL, PostgreSQL и DB2.

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

Ответ 25

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

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

Ответ 26

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

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

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

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

Ответ 27

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

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

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

Ответ 28

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

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

Ответ 29

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

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