Чому реляційні бази даних приймають лише запити 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 - не.

На базі даних є ще багато чого для адміністративних цілей, тому важлива можливість сценарію та подання тексту для додавання користувачів, запуску резервних копій, завантаження даних, зміни схеми тощо. Більшість DBA не хочуть робити це всередині якоїсь іншої мови програмування.

Якщо бажання DBA захотіти на SQL, ви повинні мати іншу мову, база даних буде тягарем обробки обох.

У базах даних є багато нових функцій, тому я не думаю, що вони застійні. Вони просто не роблять того, що ви пропонуєте чомусь.

SQL Server має можливість виконувати .NET-код зсередини через SQL CLR. Це корисно для деяких із тих завдань, які не вписуються у реляційну модель, але хочуть підтримувати продуктивність. Я розумію, що це не те, що ви шукаєте. Це приклад багатьох речей, якими займаються бази даних.

Це скоро не піде. Однією з останніх баз даних для виходу на ринок є NuoDB . Вони зберігали SQL, надавали ACID, додаючи можливість розподіляти сервери та запускати його у хмарі. Можливо, ви захочете розібратися, чому вони пішли на всю цю проблему, щоб сприяти продовженню SQL (Не єдина їхня причина, але це величезна точка продажу).

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

Зауваження, що база даних не працює, не застосовується в ряді випадків і насправді не має прямого значення.

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

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

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