Почему реляционные базы данных принимают только SQL-запросы?

15

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

Я думаю, как было бы легче, если бы можно было сделать:

var result = mysql.select('article', {id: 3})

Для объединенных таблиц это будет немного сложнее, но все же возможно. Например:

var tables = mysql.join({tables: ['article', 'category'], on: 'categoryID'});
mysql.select(tables, {'article.id': 3}, ['article.title', 'article.body', 'category.categoryID'])

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

Есть ли конкретная причина, по которой он был выбран для предоставления доступа к запросам только через SQL?

lortabac
источник
14
Что делает ваш первый пример, который ORM уже не предоставляет?
Роберт Харви
4
Ваш путь работал бы отлично, если бы кто-то делал только простые запросы.
Blrfl
5
@RobertHarvey Ничего. Но это должно быть преобразовано в SQL. Суть моего вопроса в том, почему мы не можем получить доступ на уровне драйвера к операциям манипулирования данными.
lortabac
20
Для меня это все равно, что спросить, почему тостеры не принимают мороженое.
HLGEM
2
Кто-то уже подумал о том, что ты думаешь, и сделал еще один шаг вперед, и таким образом ORM родились.
Маффин Ман

Ответы:

33

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

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

Тим
источник
17
Я не согласен с созданием команд SQL вручную. ORM отлично подходит для очень упрощенных моделей данных. Все, кроме тривиального, вы пишете свой собственный слой SQL.
Мартин Йорк,
2
Я буду играть адвокат дьяволов и обратите внимание, что любой разумный ORM должен быть настраиваемым для удовлетворения потребностей приложения.
bunglestink
7
@LokiAstari: Да, но тривиальные элементы CRUD могут составлять до 80% или более от вашего приложения.
Роберт Харви
@ Тим, отлично. Фактически, гипотетический синтаксис, предложенный в вопросе, очень похож на JSON.
Джон М Гант
JSON - это формат инкапсуляции и передачи данных, а не язык.
Крейг
35

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

Если бы это было сделано по-вашему, каждая база данных SQL имела бы свой API. Если, конечно, мы все не стандартизировали ваш API. Но тогда у нас снова будет SQL, более или менее, не так ли? За исключением того, что ваш API, похоже, зависит от языка программирования, а SQL - нет.

Роберт Харви
источник
7

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

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

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

SQL Server имеет возможность выполнять код .NET изнутри через SQL CLR. Это полезно для некоторых из тех задач, которые не вписываются в реляционную модель, но хотят поддерживать производительность. Я понимаю, что это не то, что вы ищете. Это пример того, что делают базы данных.

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

JeffO
источник
Код .NET в SQL Server на самом деле не работает внутри ядра базы данных. Это код .NET, скомпилированный в сборку на сервере, а хранимые процедуры относятся к статическим методам класса, которые сервер базы данных знает, как вызывать. Методы используют поставщика данных и устанавливают соединение с базой данных, как и любой другой код .NET. У вас похожая ситуация с базами данных (Oracle, Sybase), которые поддерживают хранимые процедуры Java. SQL, с другой стороны, является «родным интерфейсом» базы данных, аналогичен для большинства продуктов баз данных и фактически анализируется и выполняется непосредственно в базе данных.
Крейг,
@Craig - Отличная мысль.
Джеффо
3

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

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

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

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

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

Пекка
источник