SQLデータベースを使用する理由
Stackoverflowがそのような一般的な質問の場所であるかどうかはよくわかりませんが、試してみましょう。
アプリケーションデータをどこかに保存する必要性にさらされているため、常にそのように実行されるという理由だけで、MySQLまたはsqliteを常に使用しています。全世界がこれらのデータベース（ほとんどすべてのソフトウェア製品、フレームワークなど）を使用しているように思えるので、私のような初心者の開発者にとって、これが良いソリューションであるかどうかについて考えることはかなり困難です。
アプリケーションにオブジェクト指向のロジックがあり、オブジェクトは何らかの形で互いに関連しているとしましょう。このロジックをストレージロジックにマップする必要があるため、データベースオブジェクト間の関係も必要です。これにより、リレーショナルデータベースを使用することになりました。それで問題ありません。簡単に言うと、データベーステーブルの行は、他のテーブルの行への参照を必要とする場合があります。 しかし、なぜそのようなデータベースとの対話にSQL言語を使用するのですか？
SQLクエリはテキストメッセージです。これが実際に何をするのかを理解するのにこれはクールだと理解できますが、展開後に誰も見なかったアプリケーションの一部にテキストテーブル名と列名を使用するのは愚かではないでしょうか。データストレージを最初から記述する必要がある場合、この種のソリューションを使用したことはありません。個人的には、クライアントアプリケーション内で一度アセンブルされてデータベースに渡される「コンパイル済みdbクエリ」バイトコードを使用していました。そして、それは確かに、ASCII文字列ではなく、ID番号でテーブルとコロンに名前を付けます。テーブル構造が変更された場合、これらのバイトクエリは、新しいdbスキーマに従って再コンパイルされ、XMLなどで保存されます。
私のアイデアの問題は何ですか？自分で作成せず、代わりにSQLデータベースを使用する理由はありますか？
[〜＃〜] edit [〜＃〜]私の質問をより明確にするため。ほとんどの回答は、テキストクエリであるSQLは、開発者がクエリ自体をよりよく理解し、より簡単にデバッグするのに役立つと主張しています。個人的には、SQLクエリを手書きで書いている人はしばらく見ていません。私を含め、私が知っている誰もがORMを使用しています。 SQLを隠すために新しいレベルの抽象化を構築するこの状況は、SQLが必要かどうかを考えることにつながります。 SQLがORMなしで意図的に使用されている例とその理由を教えていただければ幸いです。
EDIT2 SQLは、人間とデータベースの間のインターフェースです。問題は、アプリケーション/データベースとのやり取りに使用する必要があるのはなぜですか？SQLを作成/デバッグする人間の例を引き続き求めています。
必要なことは、アプリケーションデータをどこかに保存することだけであれば、汎用RDBMSまたはSQLiteでさえもやりすぎかもしれません。オブジェクトをシリアル化してファイルに書き込む方が簡単な場合があります。 SQLiteの利点は、この種の情報がたくさんある場合、すべて1つのファイルに含まれることです。欠点は、読みにくいことです。たとえば、データをYAMLにシリアル化する場合、任意のテキストエディターまたはシェルでファイルを読み取ることができます。
個人的には、クライアントアプリケーション内で一度アセンブルされてデータベースに渡される「コンパイル済みdbクエリ」バイトコードを使用していました。
これがいくつかのデータベースAPIの動作方法です。静的SQLおよび準備済みステートメントをチェックアウトします。
自分で作成せず、代わりにSQLデータベースを使用する理由はありますか？
多くの機能が必要な場合は、ある時点で既存のRDMBSを使用してから、独自のデータベースを最初から作成する方が簡単になります。多くの機能が必要ない場合は、よりシンプルなソリューションが賢明かもしれません。
データベース製品の重要なポイントは、新しいプログラムごとにデータベース層を作成しないことです。はい、最新のRDMBSは必ずしもすべてのプロジェクトに完全に適合するとは限りません。これは、それらが非常に一般的であるように設計されているためです。したがって、実際には、必要のない追加機能を常に取得できます。だからといって、カスタムソリューションを用意したほうがよいというわけではありません。手袋は常に完璧にフィットする必要はありません。
UPDATE：
しかし、なぜそのようなデータベースとの対話にSQL言語を使用するのでしょうか？
良い質問。
その答えは、リレーショナルモデルを説明する元の論文で見つけることができます 大規模な共有データバンクのデータのリレーショナルモデル 、EF Codd、1970年にIBMが発行しました。この論文では、当時の既存のデータベーステクノロジー、およびリレーショナルモデルが優れている理由を説明しています。
リレーショナルモデル、つまりSQLのような論理クエリ言語を使用する理由は、データの独立性です。
データの独立性は、論文では次のように定義されています。
「...データ型の成長とデータ表現の変化からのアプリケーションプログラムと端末アクティビティの独立性。」
リレーショナルモデルの前は、データベースの主要なテクノロジーはネットワークモデルと呼ばれていました。このモデルでは、プログラマはデータのディスク上の構造を把握し、ツリーまたはグラフを手動で走査する必要がありました。リレーショナルモデルを使用すると、ディスク上のデータの物理表現に依存しない概念または論理スキームに対してクエリを作成できます。論理スキーマと物理スキーマのこの分離が、リレーショナルモデルを使用する理由です。この問題の詳細については、 here はデータベースクラスのスライドです。リレーショナルモデルでは、SQLなどのロジックベースのクエリ言語を使用してデータを取得します。 Coddの論文 では、リレーショナルモデルの利点について詳しく説明します。それを読んでください。
SQLは、研究論文で通常使用されるクエリ言語とは対照的に、コンピューターに簡単に入力できるクエリ言語です。研究論文は一般に関係代数または関係計算を使用してクエリを記述します。
要約すると、データベースにリレーショナルモデルを使用しているため、SQLを使用します。
リレーショナルモデルを理解していれば、SQLがそうである理由を理解するのは難しくありません。したがって、基本的に、SQLを使用する理由を本当に理解するには、リレーションモデルとデータベース内部をより深く研究する必要があります。それ以外の場合は少し謎かもしれません。
更新2：
SQLは、人間とデータベースの間のインターフェースです。問題は、なぜアプリケーション/データベースの相互作用に使用する必要があるのかということです。私は今でも、SQLを作成/デバッグする人間の例を求めています。
データベースはリレーショナルデータベースであるため、リレーショナルクエリ言語のみを理解します。内部的には、クエリを指定するための言語のようなリレーショナル代数を使用し、クエリはクエリプランになります。そのため、クエリを理解できる形式（SQL）で記述します。DBはSQLクエリを受け取り、内部クエリ言語に変換します。次に、クエリを受け取り、クエリを実行するための「クエリプラン」を見つけようとします。次に、クエリプランを実行し、結果を返します。
ある時点で、データベースが理解できる形式でクエリをエンコードする必要があります。データベースは、SQLをその内部表現に変換する方法のみを知っています。そのため、チェーンのある時点で常にSQLが存在します。それは避けられません。
ORMを使用する場合、SQLの上にレイヤーを追加するだけです。 SQLはまだ存在し、隠されています。リクエストをSQLに変換するための上位層がある場合、SQLを直接記述する必要はありません。これは場合によっては有益です。時には、必要な種類のクエリを実行できるようなレイヤーがないため、SQLを使用する必要があります。
私を含め、私が知っている誰もがORMを使用しています
奇妙な。私を含め、私が知っている誰もが、ほとんどのSQLを手で書いています。通常、生成されたソリューションを使用する場合よりも、よりタイトで高性能なクエリが作成されます。そして、あなたの業界とアプリケーションに応じて、この速度doesが重要です。時々たくさん。ええ、私はLINQを使用して、結果のSQLがどのように見えるかをあまり気にしないクイックnダーティに時々使用しますが、これまでのところ、負荷環境は本当に重要です。
MySQLとSQLiteを使用したという事実を考えると、私はあなたの見解を完全に理解しています。ほとんどのDBMSには、データベースから無料で入手できる一方で、一部のプログラミングが必要になる機能があります。
インデックス-インデックスのため、大量のデータを保存しながら、非常に迅速にフィルタリングおよび検索を行うことができます。もちろん、独自のインデックスを実装することもできますが、なぜホイールを再発明するのですか
データ整合性-カスケード外部キーなどのデータベース機能を使用すると、システム全体でデータ整合性を確保できます。データ間の関係を宣言するだけで、残りはシステムが処理します。もちろん、コードに制約を実装することもできますが、より多くの作業が必要です。たとえば、削除を検討します。ここでは、オブジェクトのデストラクタでコードを記述して、すべての依存オブジェクトを追跡し、それに応じて行動する必要があります。
複数のアプリケーションさまざまなプログラミング言語で記述され、さまざまなオペレーティングシステムで動作し、一部はネットワーク全体に分散する機能-すべてを使用して同じデータを共通データベースに保存
トリガーを介したobserver patternの非常に簡単な実装。一部のデータのみが他のデータに依存し、アプリケーションのUIの側面に影響を与えない場合が多くあります。一貫性を確保することは非常に難しいか、多くのプログラミングを必要とします。もちろん、オブジェクトでトリガーのような動作を実装できますが、単純なSQL定義よりも多くのプログラミングが必要です
ここにはいくつかの良い答えがあります。 2セントを追加しようとします。
私はSQLが好きです、私はそれをかなり簡単に考えることができます。 DB上のレイヤー（ORMフレームワークなど）によって生成されるクエリは、通常、恐ろしいものです。たくさんの余分なものを選択したり、不要なものに参加したりします。これは、このコードでオブジェクトの一部のみが必要であることを彼らが知らないためです。高いパフォーマンスが必要な場合、多くの場合、ORMシステムで少なくともいくつかのカスタムSQLクエリを使用して、いくつかのボトルネックをスピードアップします。
なぜSQLなのか？他の人が言ったように、それは人間にとって簡単です。これは、最小公分母として適切です。必要に応じて、どの言語でもSQLを作成し、コマンドラインクライアントを呼び出すことができ、ほとんどの場合、これらは優れたライブラリです。
SQLの解析は非効率ですか？幾分。文法はかなり構造化されているので、パーサーの仕事を本当に難しくするような曖昧さはあまりありません。実は、SQLを解析するオーバーヘッドは基本的にはゼロです。
「SELECT x FROM table WHERE id = 3」のようなクエリを実行し、4、5を何度も繰り返して実行するとします。その場合、解析のオーバーヘッドが存在する可能性があります。だからこそ（他の人が述べたように）声明を準備したのです。サーバーはクエリを1回解析し、すべてを再解析することなく3と4と5を交換できます。
しかし、それは些細なケースです。実際には、システムは6つのテーブルを結合し、数十万のレコード（それ以上でない場合）をプルする必要があります。それはあなたのケースで物事を行うための最良の方法だから、それはあなたがデータベースクラスタ上で数時間実行させるクエリかもしれません。クエリの実行に1〜2分しかかからない場合でも、クエリを解析する時間は、ディスクからレコードを取り出してソート/集計などを行うのに比べて、基本的に無料です。 ext "LEFT OUTER JOIN ON"を送信するオーバーヘッドは、特別にエンコードされたバイト0x3Fを送信する場合と比べてわずか数バイトです。ただし、結果セットが30 MBの場合（gigs +は言うまでもありません）、これらのいくつかの余分なバイトは、特別なクエリコンパイラオブジェクトを台無しにする必要がないのに比べて価値がありません。
多くの人が小さなデータベースでSQLを使用しています。私がやり取りする最大のものは、ほんの数ダースのギグです。 SQLは、小さなファイル（小さなSQLite DBのような）からテラバイトサイズのOracleクラスターまでのすべてで使用されます。その力を考えると、実際には驚くほどシンプルで小さなコマンドセットです。
しかし、なぜそのようなデータベースとの対話にSQL言語を使用するのでしょうか？
コンパイラとの対話に人間が読める（ソースコード）言語を使用するのも同じ理由によると思います。
個人的には、クライアントアプリケーション内で一度アセンブルされてデータベースに渡される「コンパイル済みdbクエリ」バイトコードを使用していました。
これは、データベースの既存の（オプションの）機能であり、「ストアドプロシージャ」と呼ばれます。
編集：
SQLがORMなしで意図的に使用されている例をいくつか挙げていただければ幸いです。
自分でORMを実装したとき、ADO.NETを使用してORMフレームワークを実装しました。ADO.NETを使用すると、その実装でSQLステートメントを使用できます。
- それはユビキタス標準です。ほとんどのプログラミング言語には、SQLデータベースにアクセスする方法があります。独自のバイナリプロトコルで試してください。
- 誰もが知っています。エキスパートを簡単に見つけることができ、新しい開発者は通常、トレーニングを必要とせずにある程度理解します。
- SQLは、最適化と拡張性に関して徹底的に調査されたリレーショナルモデルと密接に結びついています。ただし、手動の調整（インデックス作成、クエリ構造など）が頻繁に必要になります。これは、テキストインターフェイスのため比較的簡単です。
すべての編集とコメントの後、あなたの質問の主なポイントは次のように見えます：なぜSQLの性質はアプリケーション/データベースインターフェースよりも人間/データベースインターフェースに近いのですか？
thatの質問に対する非常に単純な答えは、それがまさに本来意図されていたものだからです。
SQLの前身（おそらく最も重要なものはQUEL）は、まさにQUERY言語、つまりINSERT、UPDATE、DELETEのいずれも持たない言語であることが意図されていました。
さらに、ユーザーがデータベースの論理構造を認識し、使用しているクエリ言語でその論理構造を表現する方法を明らかに知っていれば、すべてのユーザーが使用できるクエリ言語になることを意図していました。
QUEL/SQLの背後にある当初のアイデアは、「考えられるあらゆるメカニズム」を使用してデータベースを構築し、「実際の」データベースは実際には何でもかまわないというものでした（たとえば、1つの巨大なXMLファイル-「XML」当時）、そして、その「ちょうど何でも」の実際の構造をSQLユーザーが認識した論理的な関係構造に変換する方法を理解した「何らかの機械」があるでしょう。
それを実際に達成するためには、基礎となる構造が「関係的にそれらを見る」ことに役立つことが必要であるという事実は、当時のままでは理解されていませんでした。
はい、オブジェクトを保存および取得するためにSQLステートメントを記述する必要があるのは面倒です。
マイクロソフトがLINQ（言語統合クエリ）などをC＃とVB.NETに追加して、文字列の代わりにオブジェクトとメソッドを使用してデータベースをクエリできるようにしたのはそのためです。
他のほとんどの言語には、その言語の能力に応じてさまざまな成功レベルで似たようなものがあります。
一方、SQLがどのように機能するかを知ることは有用であり、SQLから完全に保護するのは間違いだと思います。考えずにデータベースを使用すると、非常に非効率的なクエリを記述し、データベースのインデックスを誤って作成する可能性があります。しかし、SQLの正しい使用方法を理解し、データベースを調整すると、非常に強力な実証済みのツールを使用して、非常に迅速に必要なデータを正確に見つけることができます。
SQLの最大の理由は、アドホックレポートです。ビジネスユーザーが必要とするレポートですが、まだ必要かどうかはわかりません。
SQLはDBMSプラットフォームで使用される一般的なインターフェイスです。インターフェイスのポイントは、補足的なAPI呼び出しを必要とせずに、すべてのデータベース操作をSQLで指定できることです。これは、アプリケーションソフトウェア、レポート、アドホッククエリツールなど、システムのすべてのクライアントに共通のインターフェースがあることを意味します。
第二に、クエリが複雑になるにつれて、SQLはますます便利になります。 LINQを使用して、既存の述語に基づいた3つの条件と、サブクエリで計算された集計に基づく条件を持つ12方向の結合を指定してみてください。この種のことはSQLでかなり理解できますが、ORMで可能になることはほとんどありません。
多くの場合、ORMは必要な処理の95％を実行します。アプリケーションによって発行されるクエリのほとんどは、ORMまたはその他の汎用データベースインターフェイスメカニズムが簡単に処理できる単純なCRUD操作です。一部の操作は、カスタムSQLコードを使用して行うのが最適です。
ただし、ORMはデータベースインターフェースのすべてではありません。ファウラーのエンタープライズアプリケーションアーキテクチャのパターンには、他の種類のデータベースアクセス戦略に関する非常に優れたセクションがあり、それぞれのメリットについていくつか説明しています。
多くの場合、プライマリデータベースインターフェイスレイヤーとしてORMを使用しないのには十分な理由があります。良い例の1つは、ADO.Netのようなプラットフォームデータベースライブラリがしばしば十分な仕事をし、環境の他の部分とうまく統合することです。他のインターフェイスを使用することで得られる利益は、統合による利点を実際には上回らないことがわかるかもしれません。
ただし、SQLを実際に無視できない最後の理由は、データベースアプリケーションを実行している場合、最終的にデータベースを操作していることです。データベースを適切に理解していない人々によって行われた商用アプリケーションコードのねじ込みに関する多くのWTFストーリーがあります。よく考えられていないデータベースコードは非常に多くの点で問題を引き起こす可能性があり、DBMSの仕組みを理解する必要がないと気楽に考えることは、いつか来てあなたに噛み付くはずのHubrisの行為です。さらに悪いことに、それはあなたのコードを継承する他の貧しいシュモエを噛みつきます。
SQLは、人間とデータベースの間のインターフェースです。問題は、なぜアプリケーション/データベースの相互作用に使用する必要があるのかということです。私は今でも、SQLを作成/デバッグする人間の例を求めています。
私の日常の研究では、最も単純なタスク（sqliteデータベースに直接ファイアウォールログを記録するなど）から、より複雑な分析およびデバッグタスクまで、sqliteを多く使用しています。これらの状況では、データをテーブルに配置し、SQLクエリを作成して興味深い方法でそれらを変更するのが最も自然なことのようです。
アプリケーション/データベース間のインターフェイスとしてまだ使用されている理由についてのあなたのポイントでは、これは私の簡単な理由です：
1970年に関係代数に関するコッドの独創的な論文から始まって、その分野で約30から40年の真剣な研究があります。リレーショナル代数は、SQL（および他のQL）の数学的基礎を形成しますが、SQLはリレーショナルモデルに完全には準拠していません。
「テキスト」形式の言語（人間が簡単に理解できることは別として）も、マシンで簡単に解析でき（たとえば、Lexのような文法パーサーを使用）、任意の数の最適化を使用して「バイトコード」に簡単に変換できます。
他の方法でこれを行うと、一般的なケースで説得力の利点が得られるかどうかはわかりません。そうでなければ、おそらく30年の研究で発見され、採用されていただろう。 SQLは、人間/データベースとアプリケーション/データベースの境界を橋渡しする際に、おそらく最良のトレードオフを提供します。
それから質問するのが面白くなってくる質問は、「SQLを他の「非テキスト」方法で実行することの本当の利点は何ですか？」です。今すぐこれをグーグルで検索します:)
質問の前提は間違っていると思います。 SQLがテキストとして表現できることは重要ではありません。最新のデータベースのほとんどは、クエリを1回だけコンパイルし、とにかくそれらをキャッシュするため、事実上「コンパイル済みのバイトコード」をすでに持っています。そして、これがクライアントごとに起こらない理由はありませんが、誰かがそれをやったかどうかはわかりません。
SQLはテキストメッセージだと言っていましたが、私は彼をメッセンジャーだと考えています。本当の問題は、関係が現実世界のデータを整理するのに十分な方法ではないということです。 SQLは豚の口紅にすぎません。
私はあなたの意見を見ていますが、SQLのクエリ言語は、特に大量のデータを扱う大規模なアプリケーションで、場所を持っています。そして、明白なことを指摘するために、言語がなければ、SQL（Structured Query Language）と呼ぶことはできません。説明した方法よりもSQLを使用する利点は、一般にSQLが非常に読みやすいことです。
私はMark Byersに心から同意します。SQLから身を守るべきではありません。開発者は誰でもSQLを作成できますが、アプリケーションをSQLインタラクションで適切に実行するには、言語を理解する必要があります。
あなたが説明したようにすべてがバイトコードでプリコンパイルされている場合、元の開発者が去った後（または6ヶ月間コードを見なかった後でも）、アプリケーションをデバッグしなければならないのは嫌です。
このように、Unixの設計原則の1つは、「テキストストリームを処理するプログラムを作成することです。これはユニバーサルインターフェイスであるためです。」.
そして、それが、コンパイルインターフェイスのみを備えた「バイトSQL」ではなく、通常SQLを使用する理由だと思います。 didバイトSQLを使用している場合でも、誰かが「テキストSQL」を作成し、ループが完了します。
また、MySQLとSQLiteは、たとえばMSSQLやOracle SQLよりも十分な機能を備えていません。したがって、あなたはまだSQLプールの低価格帯にいます。
実際には、SQL以外のデータベース（Objectivity、Oracle Berkeley DBなど）の製品がいくつかありましたが、成功しなかった製品がいくつかあります。将来、誰かがSQLの直感的な代替を見つけた場合、それはあなたの質問に答えます。
SQLは、リレーショナルデータベースに対してアドホッククエリを作成するためのインターフェイスを提供するために作成されました。
一般に、ほとんどのリレーショナルデータベースは、何らかの形式のSQLを理解します。
オブジェクト指向のデータベースが存在し、（おそらく）オブジェクトを使用してクエリを実行します...しかし、私が理解しているように、OOデータベースはずっと耳にされており、リレーショナルデータベースは問題なく動作します。
リレーショナルデータベースを使用すると、「切断」状態で操作することもできます。要求した情報を入手したら、データベース接続を閉じることができます。 OOデータベースでは、現在のオブジェクトに関連するすべてのオブジェクト（およびそれらが関連する...および.........）を返す必要があります。アクセス時に新しいオブジェクトを取得する接続。
SQLに加えて、オブジェクトをSQLにマッピングしたり戻したりするORM（オブジェクトリレーショナルマッピング）もあります。 LINQ（.NET）、MS Entity Framework（.NET）、Hibernate（Java）、SQLAlchemy（Python）、ActiveRecord（Ruby）、Class :: DBI（Perl）などを含むそれらの多くがあります。 。
最初の部分は、通常オブジェクトと呼ばれるもの-リレーショナルマッピングインピーダンスを参照しているように見えます。その問題を軽減するためのフレームワークはすでにたくさんあります。トレードオフもあります。より簡単になるものもあれば、より複雑になるものもありますが、一般的な場合、追加のレイヤーを購入する余裕があればうまく機能します。
2番目の部分では、SQLがテキストであることについて文句を言うようです（IDの代わりに文字列を使用するなど）。SQLはクエリ言語です。 言語（コンピューターまたはそれ以外）が人間によって読み書きされることを意図しているものはすべて、テキスト指向です。アセンブリ、C、PHP、名前を付けます。どうして？なぜなら、それは理にかなっているからですよね？
プリコンパイルされたクエリが必要な場合は、既にストアドプロシージャがあります。準備されたステートメントは、IIRCで1回もコンパイルされます。ほとんどの（すべてではないにしても）dbドライバーは、とにかくバイナリプロトコルを使用してデータベースサーバーと通信します。
はい、テキストは少し非効率的です。しかし、実際にデータを取得するのははるかにコストがかかるため、テキストベースのSQLはそれほど重要ではありません。
データベース言語は、それを使用するアプリケーションとは無関係にデータの論理モデルを提供するので便利です。 SQLには多くの欠点がありますが、少なくとも他の言語との統合が貧弱であり、型サポートは業界の他の部分よりも約30年遅れており、とにかく真のリレーショナル言語ではありません。
SQLは、データベース市場が投資の保護に既得権益を持つ3つのメガベンダーに支配されているため、ほとんど生き残っています。それは変化しており、SQLの日はおそらく番号が付けられていますが、最終的にそれを置き換えるモデルはおそらくまだ到着していません-この頃は多くの競合者がいますが。
ほとんどの人があなたの質問を受け取っているとは思わないが、それは非常に明確だと思う。残念ながら、「正しい」答えがありません。私はそれがいくつかのことの組み合わせだと思います：
- 使いやすさ、SQLコンパイラ（またはIDE）の必要なし、移植性など、設計時の半任意の決定.
- うまくいきました（おそらく同様の理由による）
- そして現在、歴史的な理由（互換性、よく知られている、実証済みなど）が引き続き使用されています。
- ほとんどの企業は別のソリューションに悩まされているとは思いません。それはうまく機能し、ボトルネックではなく、標準的なものだからです。
多くの場合、（あなたを引用して）"展開後に誰も見たことがない"であると確信できないからです。レポート作成およびデータセットレベルのクエリのための簡単なインターフェイスがあることを知っていることは、アプリの進化にとって良い道です。
あなたは正しい、いくつかの状況で有効な他の解決策があることは正しい：XML、プレーンテキストファイル、OODB ...
ただし、一連の共通インターフェース（ODBCなど）があることは、データの寿命にとって大きなプラスになります。
多くの非リレーショナルデータベースシステムがあります。以下にほんの一部を示します。 MemcachedTokyo Cabinet
その理由は、SQL言語が接続されている検索/検索/グラブアルゴリズムにあると思います。 sqlは40年間開発されていることを忘れないでください-そして、目標は賢明な先行性と賢明なユーザーの両方でした。
2つの属性を見つけるための最良の方法は何かを自問してください。では、アプリケーションを開発するたびにそれを含む何かをしたいと思うたびに、なぜ調査するのでしょうか。主な目標は、アプリケーションを開発するときにアプリケーションを開発することです。
アプリケーションには他のアプリケーションとの類似点があり、データベースには他のデータベースとの類似点があります。したがって、論理的に相互作用するこれらの「最良の方法」があるはずです。
また、SQL言語を使用しない、より優れたコンソールのみのアプリケーションをどのように開発するかを自問してください。それができない場合、コンソールよりも根本的に使いやすい新しい種類のGUIを開発する必要があると思います-それから物事を開発します。そして、それは実際に可能かもしれません。それでも、アプリケーションの開発の大部分はコンソールとタイピングに基づいています。
それから、laungageに関しては、sqlよりもはるかに基本的に簡単なテキストlaungageを作成できるとは思いません。そして、すべての言葉はそれぞれの意味に密接に関係していることを覚えておいてください-意味を削除すると、その言葉は使用できなくなります-言葉を削除すると、意味を伝えることができなくなります。それを説明するものは何もありません（そして、それまで考えたことのある他の何かに接続されないため、それを考えることさえできないかもしれません...）。
したがって、基本的にデータベース操作の最適なアルゴリズムは単語に割り当てられます-これらの単語を削除すると、これらの操作に別の何かを割り当てる必要があります-それはどうなりますか？
SQLを主要なインターフェイスとして使用しないリレーショナルデータベースを見つける限り、あなたはそれを見つけないと思います。理由：SQLは関係について話すのに最適な方法です。なぜそれがあなたにとって大したことなのかわかりません。SQLが気に入らない場合は、それを抽象化して（ORMなど）、心配する必要はありません。抽象化に心配させてください。同じ場所に移動します。
しかし、あなたがreallyで言及している問題は、オブジェクトとの関係の切断です。問題はリレーション自体にあります。オブジェクトとリレーショナルタプルは常に1対1の関係になるとは限りません。これが、開発者がデータベースにイライラする理由です。これに対する解決策は、異なるデータベースタイプを使用することです。