Mengapa database relasional hanya menerima permintaan SQL?

Sejauh yang saya tahu, sebagian besar basis data relasional tidak menawarkan API tingkat driver apa pun untuk kueri, kecuali queryfungsi yang menggunakan string SQL sebagai argumen.

Saya sedang berpikir betapa mudahnya jika seseorang dapat melakukan:

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

Untuk tabel bergabung, itu akan menjadi sedikit lebih kompleks, tetapi masih mungkin. Sebagai contoh:

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

Kode bersih, tidak ada string parsing overhead, tidak ada masalah injeksi, penggunaan kembali elemen query lebih mudah ... Saya bisa melihat banyak keuntungan.

Apakah ada alasan khusus mengapa itu dipilih untuk hanya menyediakan akses ke pertanyaan melalui SQL?

Database sedang dalam proses - biasanya berjalan di server yang berbeda. Jadi, bahkan jika Anda memiliki API, itu perlu mengirim sesuatu di kawat yang mewakili permintaan Anda dan semua proyeksi, filter, grup, subqueries, ekspresi, bergabung, fungsi agregat dll. Sesuatu itu bisa XML atau JSON atau format berpemilik, tetapi mungkin juga SQL karena itu sudah dicoba, diuji, dan didukung.

Dewasa ini lebih jarang membuat perintah SQL sendiri - banyak orang menggunakan semacam ORM. Meskipun ini akhirnya diterjemahkan ke dalam pernyataan SQL, mereka dapat memberikan API yang Anda cari.

Karena SQL menyediakan API umum. Anda dapat menulis driver yang sesuai dengan ANSI 92 SQL yang memancarkan SQL dan memperlihatkan API yang Anda inginkan. Sebagai bonus khusus, ini akan bekerja dengan hampir semua basis data SQL tanpa menulis ulang.

Jika itu dilakukan dengan cara Anda, setiap database SQL akan memiliki API yang berbeda. Kecuali, tentu saja, kita semua distandarisasi pada API Anda. Tetapi kemudian, kita akan memiliki SQL lagi, kurang lebih, bukan? Kecuali bahwa API Anda tampaknya khusus untuk bahasa pemrograman, sedangkan SQL tidak.

Ada lebih banyak yang harus dilakukan pada database untuk keperluan administrasi, sehingga dapat membuat skrip dan mengirim teks untuk menambahkan pengguna, menjalankan backup, memuat data, mengubah skema, dll. Adalah penting. Kebanyakan DBA tidak akan mau melakukan ini di dalam beberapa bahasa pemrograman lain.

Jika DBA ingin berpegang pada SQL, Anda harus memiliki bahasa lain, database akan memiliki beban memproses keduanya.

Ada banyak fitur baru dalam database, jadi saya tidak berpikir mereka menjadi stagnan. Mereka hanya tidak melakukan apa yang Anda usulkan karena suatu alasan.

SQL Server memiliki kemampuan untuk mengeksekusi kode .NET dari dalam melalui SQL CLR. Ini berguna untuk beberapa tugas yang tidak cocok dengan model relasional, tetapi ingin mempertahankan kinerja. Saya sadar ini bukan yang Anda cari. Ini adalah contoh dari banyak hal yang dilakukan database.

Ini tidak akan pergi dalam waktu dekat. Salah satu basis data terbaru yang beredar di pasaran adalah NuoDB . Mereka menyimpan SQL, menyediakan ACID sambil menambahkan kemampuan untuk mendistribusikan server dan menjalankannya di cloud. Anda mungkin ingin melihat mengapa mereka pergi ke semua masalah untuk mempromosikan kelanjutan dari SQL (Bukan satu-satunya alasan mereka, tetapi itu adalah nilai jual yang sangat besar.).

SQL DBMS menyediakan akses yang dioptimalkan secara substansial ke toko melalui bahasa asli dan banyak, karena Anda perhatikan tidak menyediakan API lain.

Pengamatan bahwa database sedang dalam proses tidak berlaku dalam sejumlah kasus dan tidak benar-benar relevan.

Bahkan database yang memerlukan penggunaan DML SQL sering menyediakan pustaka kursor untuk memberikan akses iterator ke set hasil, dan Microsoft Access dan Btrieve SQL DBMS yang terkenal keduanya menyediakan antarmuka rekaman langsung ke masing-masing tabel dalam database sebagai mekanisme. untuk akses kinerja sangat tinggi dalam keadaan tertentu.

Sebagaimana dicatat, pertanyaan kompleks menggunakan sintaksis seperti itu akan mereproduksi perilaku database jaringan dari akhir 70-an.

Mekanisme akses alternatif kurang menarik bagi pengguna utama karena ketidaktahuan, tetapi pertumbuhan popularitas database NoSQL dapat meningkatkan minat pada API lain untuk mencapai keuntungan kinerja tertentu. Tampaknya tidak banyak yang bisa direkomendasikan untuk pendekatan semacam itu.