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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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