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

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

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

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

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

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

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

I don't dislike SQL, but I also don't want to have to write it as part of what I am developing. The DAL is not about speed to market - actually, I have never thought that there would be a DAL implementation that would be faster than direct queries from the code. But the goal of the DAL is to abstract. Abstraction comes at a cost, and here it is that it will take longer to implement.

The benefits are huge, though. Writing native tests around the code, using expressive classes, strongly typed datasets, etc. We use a "DAL" of sorts, which is a pure DDD implementation using Generics in C#. So we have generic repositories, unit of work implementations (code based transactions), and logical separation. We can do things like mock out our datasets with little effort and actually develop ahead of database implementations. There was an upfront cost in building such a framework, but it is very nice that business logic is the star of the show again. We consume data as a resource now, and deal with it in the language we are natively using in the code. An added benefit of this approach is the clear separation it provides. I no longer see a database query in a web page, for example. Yes, that page needs data. Yes, the database is involved. But now, no matter where I am pulling data from, there is one (and only one) place to go into the code and find it. Maybe not a big deal on smaller projects, but when you have hundreds of pages in a site or dozens of windows in a desktop application, you truly can appreciate it.

As a developer, I was hired to implement the requirements of the business using my logical and analytical skills - and our framework implementation allows for me to be more productive now. As a manager, I would rather have my developers using their logical and analytical skills to solve problems than to write SQL. The fact that we can build an entire application that uses the database without having the database until closer to the end of the development cycle is a beautiful thing. It isn't meant as a knock against database professionals. Sometimes a database implementation is more complex than the solution. SQL (and in our case, Views and Stored Procs, specifically) are an abstraction point where code can consume data as a service. In shops where there is a definite separation between the data and development teams, this helps to eliminate sitting in a holding pattern waiting for database implementation and changes. Developers can focus on the problem domain without hovering over a DBA and the DBA can focus on the correct implementation without a developer needing it right now.

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

Quick, write me SQL to paginate a dataset that works in MySQL, Oracle, MSSQL, PostgreSQL, and DB2.

Oh, right, standard SQL doesn't define any operators to limit the number of results coming back and which row to start at.

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

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

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

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

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

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

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

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

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

SQL is based on Set Theory, while most high level languages are object oriented these days. Object programmers typically like to think in objects, and have to make a mental shift to use Set based tools to store their objects. Generally, it is much more natural (for the OO programmer) to just cut code in the language of their choice and do something like object.save or object.delete in application code instead of having to write sql queries and call the database to achieve the same result.

Of course, sometimes for complex things, SQL is easier to use and more efficient, so it is good to have a handle on both types of technology.

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

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

Для других причины заключаются в

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Контроль видимости : не существует стандартного механизма SQL для сокрытия частей кода друг от друга или их группировки в логические единицы, такие как каждая таблица, процедура и т. Д. является accessible from every other one, even when it's undesirable.

• Modularity and Versioning

Finally, manually coding CRUD operations in SQL (and writing the code to hook it up to the rest of one's application) is repetitive and error-prone.

A modern abstraction layer provides all of those features, and allows us to use SQL where it's most effective while hiding the disruptive, repetitive implementation details. It provides tools to help overcome the object-relational impedance mismatch that complicates data access in object-oriented software development.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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