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

Насколько я знаю, большинство реляционных баз данных не предлагают 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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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