İlişkisel veritabanları neden yalnızca SQL sorgularını kabul eder?

Bildiğim kadarıyla, ilişkisel veritabanlarının çoğu, querySQL dizesini bağımsız değişken olarak alan bir işlev dışında, sorgular için herhangi bir sürücü düzeyinde API sunmaz .

Birinin yapabilmesi ne kadar kolay olurdu diye düşünüyorum:

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

Birleştirilmiş tablolar için, biraz daha karmaşık ama yine de mümkün olacaktır. Örneğin:

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

Temiz kod, dize ayrıştırma yükü yok, enjeksiyon problemi yok, sorgu elemanlarının daha kolay yeniden kullanılması ... Bir çok avantaj görüyorum.

Yalnızca SQL aracılığıyla sorgulara erişim sağlamak için seçilmesinin belirli bir nedeni var mı?

Veritabanları işlem dışı - genellikle farklı bir sunucuda çalışırlar. Bu nedenle, bir API'niz olsa bile, sorgunuzu ve tüm projeksiyonlarını, filtrelerini, gruplarını, alt sorgularını, ifadelerini, birleştirmelerini, toplama işlevlerini vb. Temsil eden tel üzerinden bir şey göndermeniz gerekir. özel biçim, ancak denenmiş, test edilmiş ve desteklenmiş olduğu için SQL de olabilir.

Bu günlerde SQL komutlarını kendiniz oluşturmak daha az yaygındır - birçok kişi bir çeşit ORM kullanır. Bunlar sonuçta SQL deyimlerine dönüşse de, peşinde olduğunuz API'yi sağlayabilirler.

Çünkü SQL ortak bir API sağlar. SQL yayan ve istediğiniz API'yi ortaya çıkaran ANSI 92 SQL uyumlu bir sürücü yazabilirsiniz. Özel bir bonus olarak, yeniden yazmadan neredeyse tüm SQL veritabanlarıyla çalışacaktır.

Bu şekilde yapıldıysa, her SQL veritabanının farklı bir API'si olur. Tabii ki, hepimiz API'nizde standardize olmadıkça. Ama sonra tekrar SQL'e sahip olurduk, az çok değil mi? Bunun dışında API'nız programlama diline özgü görünmektedir, ancak SQL değildir.

Veritabanında yönetimsel amaçlarla yapılacak daha çok şey vardır, bu nedenle kullanıcı eklemek, yedekleri çalıştırmak, veri yüklemek, şemayı değiştirmek vb. İçin metin yazabilmek ve gönderebilmek önemlidir. Çoğu DBA, bunu başka bir programlama dilinde yapmak istemez.

DBA'lar SQL'de beklemek istiyorsa, başka bir dile sahip olmanız gerekir, veritabanı her ikisini de işleme yükü olacaktır.

Veritabanlarında birçok yeni özellik var, bu yüzden durduklarını sanmıyorum. Onlar sadece bir nedenden ötürü önerdiklerini yapmıyorlar.

SQL Server, SQL CLR ile içeriden .NET kodunu yürütebilir. Bu, ilişkisel bir modele uymayan, ancak performansı korumak isteyen bazı görevler için yararlıdır. Aradığın şeyin bu olmadığını anlıyorum. Veritabanlarının yaptığı birçok şeye bir örnek.

Yakında hiç gitmeyecek. Piyasaya çıkacak en yeni veritabanlarından biri NuoDB . SQL'i tuttular, sunucu dağıtma ve bir bulutta çalıştırma yeteneği eklerken ACID sağlıyorlar. Neden SQL'in devamını teşvik etmek için tüm bu sorunlara gittiklerini incelemek isteyebilirsiniz (Tek nedeni değil, ama büyük bir satış noktası.).

SQL DBMS, başka bir API sağlamadığından, yerel dil ve birçoğu aracılığıyla mağazaya önemli ölçüde optimize edilmiş erişim sağlar.

Veritabanının işlem dışı olduğu gözlemi bazı durumlarda geçerli değildir ve gerçekten doğrudan ilgili değildir.

SQL DML'nin kullanılmasını gerektiren veritabanları bile, genellikle bir sonuç kümesine yineleyici erişimi sağlamak için bir imleç kitaplığı sağlar ve iyi bilinen Microsoft Access ve Btrieve SQL DBMS'nin her ikisi de bir mekanizma olarak veritabanındaki tek tek tablolara doğrudan kayıt arabirimi sağlar belirli koşullar altında çok yüksek performans erişimi için.

Belirtildiği gibi, böyle bir sözdizimini kullanan karmaşık sorgular, 70'lerin sonlarından itibaren ağ veritabanlarının davranışını yeniden üretecektir.

Alternatif erişim mekanizmaları, alışık olmamaları nedeniyle genel kullanıcılar için daha az caziptir, ancak NoSQL veritabanlarının popülaritesindeki artış, belirli performans kazançları elde etmek için diğer API'lara olan ilgiyi artırabilir. Böyle bir yaklaşımı önerecek çok az şey var.