Perché i database relazionali accettano solo query SQL?

I database sono fuori processo, di solito vengono eseguiti su un server diverso. Quindi, anche se disponevi di un'API, sarebbe necessario inviare qualcosa attraverso il filo che rappresenta la tua query e tutte le sue proiezioni, filtri, gruppi, sottoquery, espressioni, join, funzioni di aggregazione ecc. 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 manualmente comandi SQL: molte persone usano una sorta di ORM. Anche se alla fine si traducono in istruzioni SQL, possono fornire l'API richiesta.

Perché SQL fornisce un'API comune. È possibile scrivere un driver ANSI 92 compatibile SQL che emette SQL e espone 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, naturalmente, non siamo tutti standardizzati sulla tua API. Ma poi, avremmo di nuovo SQL, più o meno, no? Tranne che la tua API sembra essere specifica per la lingua di programmazione, mentre SQL non lo è.

C'è ancora molto da fare sul database per scopi amministrativi, quindi è importante poter scrivere script e inviare testo per aggiungere utenti, eseguire backup, caricare dati, modificare lo schema, ecc. La maggior parte degli amministratori di database non vorranno 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 elaborarli entrambi.

Ci sono molte nuove funzionalità nei database, quindi non penso che stiano diventando stagnanti. Semplicemente non stanno facendo ciò che tu proponi per qualche motivo.

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

Non sparirà presto. Uno dei database più recenti sul mercato è NuoDB . Hanno mantenuto SQL, fornito ACID aggiungendo la possibilità di distribuire server ed eseguirlo in un cloud. Potresti voler capire perché sono andati in tutti quei guai per promuovere la continuazione di SQL (non è la loro unica ragione, ma è un enorme punto di forza).

Il DBMS SQL fornisce un accesso sostanzialmente ottimizzato allo store tramite la lingua nativa e molti, come si nota, non forniscono altre API.

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

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

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

I meccanismi di accesso alternativo sono meno attraenti per gli utenti tradizionali a causa della mancanza di familiarità, ma la crescita della popolarità dei database NoSQL potrebbe aumentare l'interesse verso altre API per ottenere specifici guadagni in termini di prestazioni. Sembra che ci sia poco da raccomandare un simile approccio.