リレーショナルデータベースがSQLクエリのみを受け入れるのはなぜですか？

私の知る限り、ほとんどのリレーショナルデータベースはquery、引数としてSQL文字列を受け取る関数を除き、クエリ用のドライバレベルAPIを提供していません。

私はそれができるとしたらどれほど簡単になると思っています：

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があったとしても、クエリとそのすべてのプロジェクション、フィルター、グループ、サブクエリ、式、結合、集約関数などを表す何かをネットワーク経由で送信する必要があります。独自の形式ですが、試され、テストされ、サポートされているため、SQLである可能性もあります。

最近ではSQLコマンドを自分で作成することはあまり一般的ではありません。多くの人が何らかのORMを使用しています。これらは最終的にSQLステートメントに変換されますが、目的のAPIを提供する場合があります。

SQLは共通のAPIを提供するためです。SQLを出力し、必要なAPIを公開するANSI 92 SQL準拠のドライバーを作成できます。特別なボーナスとして、書き換えなしでほとんどすべてのSQLデータベースで動作します。

それがあなたの方法で行われた場合、すべてのSQLデータベースには異なるAPIがあります。もちろん、APIですべて標準化されている場合を除きます。しかし、その後、多かれ少なかれ、再びSQLを使用することになりますか？APIはプログラミング言語固有であるように見えますが、SQLはそうではありません。

管理目的のためにデータベースで行うべきことはほかにもあるので、ユーザーを追加したり、バックアップを実行したり、データをロードしたり、スキーマを変更したりするためにテキストをスクリプト化して送信できることが重要です。ほとんどのDBAは、他のプログラミング言語内でこれを行いたくないでしょう。

DBAがSQLに固執したい場合、別の言語が必要です。データベースは両方を処理する負担があります。

データベースには多くの新機能があるため、それらが停滞しているとは思わない。彼らはあなたが何らかの理由で提案したことをしていないだけです。

SQL Serverには、SQL CLRを介して内部から.NETコードを実行する機能があります。これは、リレーショナルモデルには適合しないが、パフォーマンスを維持したいタスクの一部に役立ちます。これはあなたが探しているものではないことを理解しています。データベースが行っている多くのことの例です。

すぐに消えることはありません。市場に出回っている最新のデータベースの1つはNuoDBです。彼らはSQLを保持し、ACIDを提供すると同時に、サーバーを分散してクラウドで実行する機能を追加しました。SQLの継続を促進するために、彼らがすべての問題に取り組んだ理由を調べてみてください（その理由だけでなく、大きなセールスポイントです）。

SQL DBMSは、他のAPIを提供しないことに注意してください。

データベースがアウトオブプロセスであるという観察は、多くの場合に適用されず、実際には直接関連していません。

SQL DMLの使用を必要とするデータベースでさえ、結果セットへの反復子アクセスを提供するカーソルライブラリを提供することが多く、よく知られているMicrosoft AccessとBtrieve SQL DBMSは両方とも、メカニズムとしてデータベース内の個々のテーブルへの直接レコードインターフェイスを提供します特定の状況下で非常に高いパフォーマンスでアクセスするため。

前述のように、このような構文を使用した複雑なクエリは、1970年代後半からのネットワークデータベースの動作を再現します。

代替アクセスメカニズムは不慣れであるため、メインストリームユーザーにとって魅力的ではありませんが、NoSQLデータベースの人気が高まると、特定のパフォーマンス向上を達成するために他のAPIへの関心が高まる可能性があります。そのようなアプローチを推奨することはほとんどないようです。