SQL（言語）に代わるものは何ですか？[閉まっている]

私は時々SQLがいかに悪いかについて物事を聞きます、そしてそれは良い言語ではありませんが、私は本当にそれに代わるものについてあまり聞きません。では、同じ目的（データベースアクセス）を果たす他の優れた言語は何ですか？SQLよりも優れているのは何ですか？この代替言語を使用する優れたデータベースはありますか？

編集：私はSQLに精通しており、常に使用しています。私はそれに問題はありません。存在する可能性のある代替案と、人々がそれらをよりよく好む理由に興味があります。

また、別の種類のデータベース（NoSQLの動き）を探すのではなく、データベースにアクセスするための別の方法を探しています。

SQLの構文は、自動生成の観点からも構文解析の観点からも扱いが難しいことは確かに同意します。また、配置する要求に応じてSQLを設計する場合、これは今日書いている言語のスタイルではありません。今日は。今日の言語を設計した場合、それほど多くの多様なキーワードが見つかるとは思わない。結合構文が異なるのではないかと思う。GROUP_CONCAT括弧の真ん中にキーワードをくっつけてその動作を制御するのではなく、通常の構文を使用するような関数... SQLの不整合と冗長性の独自のランドリーリストを作成します。これは、今日言語を再設計した場合にスムーズに表示されるようにしたい、または期待できるものです。

リレーショナルデータベース（つまり、プロトコルとしてのSQL）と対話するためのSQLの代替手段はありませんが、アプリケーションでSQLを作成する方法は数多くあります。これらの代替手段は、リレーショナルデータベースを操作するためのフロントエンドの形式で実装されています。フロントエンドのいくつかの例は次のとおりです。

• Lispの伝統により、おそらく最も柔軟なSchemeQLとCLSQLですが、他のフロントエンドよりもSQLのように見えます。
• LINQ（.Net）
• ScalaQLとScalaQuery（Scala内）
• RubyのSqlStatement、ActiveRecord、その他多く
• HaskellDB
• ...このリストは他の多くの言語にも当てはまります。

今日の根本的なテーマは、SQLを1つの新しいクエリ言語で置き換えるのではなく、代わりに言語固有のフロントエンドを作成して、通常の日常のプログラミング言語でSQLを非表示にし、SQL をリレーショナルと対話するためのプロトコルとして扱うことですデータベース。

このリストを見てください。

Hibernateクエリ言語がおそらく最も一般的です。Hibernateの利点は、オブジェクトがリレーショナルデータベースに非常に簡単に（ほぼ自動的に）マッピングされ、開発者がデータベース設計に多くの時間を費やす必要がないことです。詳細については、HibernateのWebサイトを確認してください。私は他の人が他の興味深いクエリ言語を使うと確信しています...

もちろん、そこにはNoSQLに関するものはたくさんありますが、それらには興味がないと具体的に述べています。

「SQLがいかに悪いかについて時々聞いており、それは良い言語ではありません。」

SQLは30年以上前のものです。「どの機能が何かを「良い」言語にするか、どの機能が「悪い」言語にするか」についての洞察は、SQL自体よりも急速に進化しています。

また、SQLは、「リレーショナルになるために必要なもの」の現在の標準に準拠した言語ではないため、起動するためのリレーショナル言語ではありません。

「しかし、それに代わるものについてはあまり聞いたことがありません。」

あなたが間違った場所（つまり、商用DBMS業界のみ）でのみ聴こうとしている可能性について考えてみてください。

「それでは、同じ目的（データベースアクセス）を果たす他の優れた言語は何ですか？SQLよりも優れているのは何ですか？」

Date＆Darwenは、最新のデータ操作言語が準拠する必要のある機能を「サードマニフェスト」で説明しています。その最新バージョンは、著書「データベース、タイプ、およびリレーショナルモデル」に記載されています。

「この代替言語を使用する優れたデータベースはありますか？」

「良い」とは、「産業の強さ」のようなものを意味し、そうではありません。利用できる最も近いものはおそらくDataphorでしょう。

Relプロジェクトは、「データベース、タイプ、およびリレーショナルモデル」で定義されたチュートリアルD言語の実装を提供していますが、Relの現在の主な目標は、本質的に教育的であることです。

私のSIRA_PRISEプロジェクトは「真にリレーショナルな」データ管理のための実装を提供していますが、「言語の実装」というラベルを付けることもためらっています。

そしてもちろん、いくつかの提案されているように、いくつかの非リレーショナルなものを検討することもありますが、私は非リレーショナルデータ管理を数十年にわたる技術的回帰として個人的に却下しています。検討する価値はありません。

ちなみに、データベースの管理に使用されるソフトウェアシステムは「データベース」ではなく、「データベース管理システム」、「DBMS」の略です。写真はカメラと同じものではなく、カメラについて議論していて混乱を避けたい場合は、「写真」ではなく「カメラ」という適切な単語を使用する必要があります。

おそらくあなたは批判を考えているでしょう。C。デートと彼の友人たちは既存のリレーショナルデータベースとSQLに対して発言しました。彼らは、システムと言語は100％リレーショナルではなく、そうである必要があると述べています。ここでは実際には問題はありません。私が見る限り、SQLの使い方を調整するだけで、100％リレーショナルシステムを使用できます。

私が個人的に実行し続けているのは、SQLがその理論的基礎である関係代数から継承する表現力の欠如です。1つの問題は、日付、タイムスタンプなどでマークされたデータを操作するときに遭遇するドメイン順序の使用のサポートの欠如です。私はかつて、タイムスタンプがいっぱいのデータベースで完全にプレーンSQLでレポートアプリケーションを作成しようとしましたが、それは現実的ではありませんでした。もう1つは、パストラバーサルのサポートがないことです。私のデータのほとんどは、パスをトラバースする必要がある有向グラフのように見えますが、SQLはそれを行うことができません。（「推移的なクロージャ」が欠けています。SQL-1999は「再帰サブクエリ」でそれを行うことができますが、実際の使用ではまだ見ていません。SQLに対応するためのさまざまなハックもありますが、醜いです。）これらの問題はちなみに、デートの著作のいくつかでも議論されました。

最近、推移的な閉鎖の問題にうまく対処していると思われる.QLが指摘されましたが、注文したドメインの問題を解決できるかどうかはわかりません。

直接的な回答：深刻な候補者はいないと思います。DBaseとその模倣者（Foxpro、Codebaseなど）はしばらくの間競争相手でしたが、基本的にデータベースクエリ言語戦争に負けたと思います。ProgressやParadoxのように独自のクエリ言語を持つデータベース製品は他にもたくさんありますが、私が使用した他のいくつかの名前は覚えていません。しかし、他の競争相手が市場の重要なシェアを獲得することに近づいたとは思いません。

データベース形式とクエリ言語に違いがあることの簡単な証明として、私が使用した最後のバージョンのDBase-何年も前-は、「従来の」DBaseクエリ言語とSQLの両方を提供し、どちらも使用できました同じデータにアクセスします。

余談：SQLが悪いとは言えませんが、多くの欠点があります。私たちの長年の経験と後知恵のおかげで、私はより優れたクエリ言語を設計できると確信しています。しかし、より優れたクエリ言語を作成し、それを使用するように人々を説得することは、2つの非常に異なるものです。学ぶのに苦労する価値があると人々に納得させるのに十分でしょうか。SQLを効果的に使用する方法を学ぶために、人々は長年にわたって投資してきました。新しい言語の方が使いやすいとしても、学習曲線は確かにあります。また、既存のシステムをSQLから新しい言語にどのように移行しますか？もちろん、C ++、C＃、JavaがCOBOLやFORTRANを大きく転覆させたのと同じように、それを行うことができます。しかし、それを成功させるには、技術的な優位性と優れたマーケティングの組み合わせが必要です。

それでも、誰かがSQLを批判するときはいつでもSQLを守るために急いで急いでいるSQLの問題は、SQLを使用する上でのあなた自身の不適切さであり、SQLの障害ではなく、SQLの欠陥ではないと主張する人々から笑いを誘います。完璧さを理解するために必要なもののより高い次元に達したなど。

LINQ to SQLを見てみましょう ...

数か月前に試してみましたが、振り返ることはありませんでした...

1980年代に戻ると、ObjectStoreは透過的なオブジェクトアクセスを提供していました。これは、RDBMSとORMのようなものでしたが、余分なリークのある抽象化レイヤーがすべてなかった点が異なります。オブジェクトをデータベースに直接保存しました。

したがって、この代替手段は本当に「まったく言語がない」、あるいは「すでに使用している言語」だったのかもしれません。C ++コードを記述し、オブジェクトをネイティブオブジェクトのように作成またはトラバースし、データベースが必要に応じてすべてを処理します。一種のActiveRecordに似ていますが、実際にはActiveRecordのマーケティングブリッツの主張と同様に機能しました。:-)

（もちろん、これにはOracleのマーケティング力がなく、MySQLのゼロコストもなかったので、誰もがそれを無視しました。そして今、RDBMSとORMでそれを複製しようとし、実際にそのテーブルについて議論しようとする人もいますオブジェクトを保存するのは理にかなっており、オブジェクトをテーブルにマップする方法をコンピューターに伝えるために巨大なXMLファイルを書き込むことは、どういうわけか合理的なソリューションです。

最近の一般的な動きはNoSQLです。通常、これらのテクノロジーは次のとおりです。

• データをキー/値のペアとして保存する分散型「ハッシュテーブル」
• ドキュメント指向データベース

個人的には、SQLがニーズに合っている限り、SQLに問題はないと思います。SQLは表現力があり、構造化データの操作に最適です。

独自のデータベースサーバー（Dを話す）を備えたオープンソースのリレーショナル開発環境であるDataphorと、そのクエリ言語からユーザーインターフェイスを派生させる機能に興味があると思います。

また、 IngresはまだQUELをサポートしており、オープンソースです。

SQLは、SQLが設計されたドメイン（相互に関連するデータのテーブル）に対しては正常に機能します。これは通常、従来のビジネスデータ処理で見られます。オブジェクトの複雑なネットワークを永続化しようとすると、SQLはうまく機能しません。

比較的伝統的なデータを格納して処理する必要がある場合は、SQLベースのDBMSを使用してください。

あなたの編集に応じて：

リレーショナルデータストアからデータを取得するためにSQL DMLに代わるものを探しているのであれば、SQLに代わる深刻な方法について聞いたことがありません。

SQLが取得するノックは、言語の基礎となっている基本的なデータストレージの原則とは対照的に、言語に対してそれほど大きなものではありません。SQL言語とRDBMSが構築されているリレーショナルデータモデルを混同することがよくあります。

リレーショナルデータベースは、唯一の種類のデータベースではありません。他の人からの応答では見たことがないので、オブジェクトデータベースについて一言言っておく必要があります。RDBMSの代わりにZODBをオブジェクトの永続性に使用するZope pythonフレームワークの経験がありました（まあ、ZODBをzope内の別のデータベースで置き換えることは理論的には可能ですが、前回確認したところ、正常に機能しなかったため、それについて前向きにならないでください）。

ZODBの考え方は本当に異なり、たまたま永続的なオブジェクトプログラミングに似ています。

ORMは一種の言語と見なすことができます

ある意味では、オブジェクトデータベースモデルがORMの目的であると私は信じています。通常のオブジェクトモデルを介して永続データにアクセスすることです。それは一種の言語であり、ある程度の市場シェアを獲得していますが、今のところ、それは言語ではなく、抽象化レイヤーとして見ています。ただし、SQLよりもオブジェクトデータベースよりもORMを使用する方が効率的だと思います（つまり、SQLデータベースをベースレイヤーとして使用してたまたま使用したORMのパフォーマンス）。

SQLには多くの実装（SQL Server、mysql、Oracleなど）がありますが、リレーショナルデータの格納と取得のために設計された汎用言語という意味で同じ目的を果たす他の言語はありません。

db4oなどのオブジェクトデータベースがあり、SQLに依存しないほぼすべてのデータストレージメカニズムを参照する同様のいわゆるnoSQLデータベースがありますが、Cassandraなどの最も一般的なオープンソース製品は、GoogleのBigtableコンセプトに大まかに基づいています。

CDFのような特別な目的のデータベース製品もいくつかありますが、おそらくそれらを心配する必要はありません-必要な場合は、ご存知でしょう。

これらはどれもSQLに相当しません。

それは、それらが「より良い」または「より悪い」という意味ではありません-それらは同じではありません。デニスフォーブスは最近、SQLに対して浮上している奇妙な主張の多くを分析した素晴らしい投稿を書きました。彼は、これらの苦情は主に、最初の仕事に間違ったツールを選択したか、SQL DBMSを適切に使用していない人々やショップに起因すると主張します（私も同意します）。すべての列がでvarchar(50)あり、単一のインデックスまたはキーがどこにもない別のSQLデータベースを参照してください）。

さらに別のソーシャルネットワーキングサイトを実装していて、ACIDの原則にあまり関心がない場合は、必ずdb4oなどの製品を検討してください。ただし、ミッションクリティカルなビジネスシステムを開発している場合は、 "SQLのサック"コーラスに参加する前によく考えることを強くお勧めします。まず調査を行い、さまざまな製品がサポートできる機能とサポートできない機能を見つけます。

編集-回答を書くのに忙しかったので、数分たっても質問の更新がありませんでした。そうは言っても、SQLは本質的にDBMS自体から切り離せません。SQLデータベース製品を実行する場合は、SQL、ピリオドでアクセスします。

おそらく、構文の抽象化を探しているでしょう。Linq to SQL、Entity Framework、Hibernate / NHibernate、SubSonic、および他の多くのORMツールはすべて、SQLではない独自のSQLのような構文を提供します。これらはすべてSQLに「コンパイルダウン」されます。SQL Serverを実行している場合は、CLR関数/プロシージャ/トリガーを作成することもできます。これにより、データベース内で実行される.NET言語でコードを作成できます。ただし、これは実際にはSQLの代わりではなく、SQLの拡張機能です。

私は、SQLデータベースの上に重ねることができる完全な「言語」を知りません。別のデータベース製品に切り替える前に、最終的にはSQLがパイプで表示されるようになります。

SQLは事実上のものです。

開発者をそこから保護しようとするフレームワークは、最終的に独自の特定の言語を作成しました（Hibernate HQLが思い浮かびます）。

SQLは問題をかなりうまく解決します。高度なプログラミング言語よりも学ぶことは難しいことではありません。すでに関数型言語を知っているなら、SQLを理解するのは簡単です。

最先端のデータベース（OracleおよびSQL Server）を提供する主要なデータベースベンダーがSQLをサポートしており、最適化エンジンなどに何年も投資しており、SQLのすべての主要なデータモデリングソフトウェアと変更管理ソフトウェアの取り引きを検討していると思います。最も安全な賭け。

また、データベースにはクエリだけではありません。スケーラビリティ、バックアップとリカバリ、データマイニングがあります。大手ベンダーは、新しい「キャッシュ」エンジンでさえ考慮していない多くのことをサポートしています。

SQLの問題により、Portland Pattern Repository wikiでSMEQLと呼ばれるドラフトクエリ言語を作成する動機になりました。コメントようこそ。関数型プログラミングとIBMの実験的なBusiness System 12言語からアイデアを借用しています。（私はもともとそれをTQLと呼んでいましたが、後でその名前が採用されたことがわかりました。）

.NETの世界では、SQL風の感覚がまだありますが、LINQ-to-SQLを使用すると、SQLとメモリ内の.NET処理をうまく組み合わせることができます。また、誰も実行したくない下位レベルのデータ配管の多くを簡素化します。

まったく異なる考え方のデータベースタイプを確認したい場合は、CouchDBをご覧ください。「より良い」は明らかに相対的な要件であり、この種の非関係データベースは「より良い」ですが、特定のシナリオでのみです。

SQLは言語が非常に強力であり、リレーショナルデータベース管理システムはこれまでも今も大成功しています。ただし、非常に高いスケーラビリティと可用性を必要とするアプリケーションのクラスがありますが、必ずしも高度なデータ整合性ではありません（最終的な整合性が重要です）。さまざまなシステムは、完全なACID準拠トランザクションの必要性を緩和することにより、RDBMSよりも優れたパフォーマンスとスケーリングを実現します。これらは「NoSQL」と呼ばれていますが、他の人が指摘しているように、これは誤称です。おそらく、それらはNoACIDデータベースと呼ばれるべきです。

Michael Stonebrakerがこれについて「No​​SQL」ディスカッションで取り上げていますが、SQLには何の関係もありません。