Perché i database relazionali accettano solo query SQL?

Per quanto ne so, la maggior parte dei database relazionali non offre alcuna API a livello di driver per le query, ad eccezione di una queryfunzione che accetta una stringa SQL come argomento.

Sto pensando a quanto sarebbe più facile se si potesse fare:

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

Per le tabelle unite, sarebbe leggermente più complesso, ma ancora possibile. Per esempio:

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

Codice più pulito, nessun overhead di analisi delle stringhe, nessun problema di iniezione, riutilizzo più semplice degli elementi della query ... Vedo molti vantaggi.

C'è un motivo specifico per cui è stato scelto di fornire l'accesso solo alle query tramite SQL?

I database sono fuori processo - di solito vengono eseguiti su un server diverso. Quindi, anche se avessi un'API, avrebbe bisogno di inviare qualcosa attraverso il filo che rappresenti la tua query e tutte le sue proiezioni, filtri, gruppi, sottoquery, espressioni, join, funzioni aggregate ecc. Che qualcosa potrebbe essere XML o JSON o alcuni formato proprietario, ma potrebbe anche essere SQL perché provato, testato e supportato.

In questi giorni è meno comune creare da soli i comandi SQL: molte persone usano una sorta di ORM. Anche se questi alla fine si traducono in istruzioni SQL, possono fornire l'API che stai cercando.

Perché SQL fornisce un'API comune. È possibile scrivere un driver conforme ANSI 92 SQL che emette SQL ed esponga l'API desiderata. Come bonus speciale, funzionerà con quasi tutti i database SQL senza riscrivere.

Se fosse fatto a modo tuo, ogni database SQL avrebbe un'API diversa. A meno che, ovviamente, non siamo tutti standardizzati sulla tua API. Ma poi avremmo di nuovo SQL, più o meno, no? Solo che l'API sembra essere specifica del linguaggio di programmazione, mentre SQL non lo è.

C'è altro da fare sul database a fini amministrativi, quindi è importante poter scrivere e inviare testo per aggiungere utenti, eseguire backup, caricare dati, modificare lo schema ecc. La maggior parte dei DBA non vorrà farlo all'interno di un altro linguaggio di programmazione.

Se i DBA vogliono aggrapparsi a SQL, devi avere un'altra lingua, il database avrebbe l'onere di elaborare entrambi.

Ci sono molte nuove funzionalità nei database, quindi non credo che stiano diventando stagnanti. Non stanno facendo quello che proponi per qualche motivo.

SQL Server ha la capacità di eseguire il codice .NET dall'interno tramite SQL CLR. Questo è utile per alcune di quelle attività che non rientrano in un modello relazionale, ma vogliono mantenere le prestazioni. Capisco che non è quello che stai cercando. È un esempio delle molte cose che stanno facendo i database.

Non scomparirà presto. Uno dei database più recenti per colpire il mercato è NuoDB . Hanno mantenuto SQL, fornito ACID e aggiunto la possibilità di distribuire server ed eseguirlo in un cloud. Potresti voler esaminare il motivo per cui hanno fatto di tutto per promuovere la continuazione di SQL (non è la loro unica ragione, ma è un enorme punto di forza).

SQL DBMS fornisce un accesso sostanzialmente ottimizzato all'archivio attraverso la lingua nativa e molti, come noterai che non forniscono altre API.

L'osservazione che il database è fuori processo non si applica in un numero di casi e non è realmente direttamente pertinente.

Anche i database che richiedono l'uso del DML SQL forniscono spesso una libreria di cursori per fornire l'accesso iteratore a un set di risultati, e il noto Microsoft Access e Btrieve SQL DBMS forniscono entrambi un'interfaccia di record diretta alle singole tabelle in un database come meccanismo per un accesso ad altissime prestazioni in circostanze specifiche.

Come notato, query complesse che utilizzano tale sintassi riproducono il comportamento dei database di rete dalla fine degli anni '70.

I meccanismi di accesso alternativo sono meno interessanti per gli utenti mainstream a causa della mancanza di familiarità, ma la crescita della popolarità dei database NoSQL potrebbe aumentare l'interesse per altre API per ottenere specifici miglioramenti delle prestazioni. Sembra poco altro per raccomandare un simile approccio.