web-dev-qa-db-ja.com

さまざまなカスタムバージョンすべてを置き換えることができる「標準」SQLはありますか?

私はSQLを10年以上書いています。私は非常に熟練しており、SQL Server、Oracle、MySQL、PostgreSQLなどでの作業経験があります。そこには複数の標準がありますが、それらは標準よりも多くの提案のようです。列タイプとストアドプロシージャについて話し始めると、全体的な一貫性はほとんどありません。

誰かが新しいクエリ言語の定義を検討したことがあるのだろうか。私は最近、いくつかのアイデアをいじってみました。次にいくつかの例を示します: https://Gist.github.com/jehugaleahsa/03888d13ef2745cb67d 。もちろん、これは最も明白なDMLをカバーするだけです。この構文により、オートコンプリートのサポートが容易になり、一時テーブルの生成をより細かく制御できるようになり、結合構文が簡単になり、グループ化されたデータの操作が簡単になり、部分式/計算の構築が簡単になります。 。一部のnoSQLデータベースもサポートするように非常に簡単に拡張できるため、特に気に入っています。委員会がもっと時間を与えられて何を思いつくことができるか想像してみてください!

私の質問は、さまざまなプロバイダーによってサポートされている、さまざまなクエリ言語の定義に何らかの努力が払われているかどうかです。 SQLは「十分に優れている」こと、そして新しい標準を定義して実装することは、途方もない仕事になることを認識しています。何年にもわたって提案されたSQL標準がたくさんあったことを私は知っています。 「SQL」以外の標準がこれまでに提案されたのか、それが進歩したのか、それとも失敗したのか、疑問に思います。

3
Travis Parks

これに対する答えはANSISQLでした。

特にOracleのようなデータベースでは、最初の採用は困難でしたが、現在ではそれらの多くがANSI標準を許可しています。

たとえば、Oracleは9iでその形式の許可を開始しました( http://allthingsoracle.com/ansi-sql/ を参照)

また、PostgreSQLは標準への準拠に誇りを持っています。そのSQL実装は、ANSI-SQL:2008標準に強く準拠しています( http://www.postgresql.org/about/

Mysqlについては、 http://dev.mysql.com/doc/refman/5.0/en/compatibility.html を参照してください。

このセクションでは、MySQLがANSI/ISOSQL標準にどのように関連しているかについて説明します。 MySQL ServerにはSQL標準に対する多くの拡張機能があり、ここでそれらが何であるか、およびそれらの使用方法を確認できます。また、MySQL Serverに欠けている機能、およびいくつかの違いを回避する方法に関する情報もあります。

SQL標準は1986年から進化しており、いくつかのバージョンが存在します。このマニュアルでは、「SQL-92」は1992年にリリースされた標準、「SQL:1999」は1999年にリリースされた標準、「SQL:2003」は2003年にリリースされた標準、「SQL:2008」は2008年にリリースされた標準の最新バージョンに。

9
Michael Durrant

... 結合構文を簡単にする、グループ化されたデータの操作を簡単にし、部分式/計算を簡単に作成できるようにします。非常に簡単に拡張できるので、特に気に入っています一部のnoSQLデータベースをサポートするため ...

ここで、すべてを支配する1つの標準が崩壊すると思います...現在のNoSQLソリューションは、そもそもネイティブでサポートしている場合でも、結合操作を実行するための従来のRDBMSほど最適ではありません。正当な理由で。確かに、彼らはこの面で改善しようとしていますが、魔法の弾丸はまだありません。そして、なぜNoSQLとRDBMSにとどまるのですか、グラフデータベースはどうですか? Cypher for Neo4j には、代わりにMATCH句があり、 'はJOINSQLに類似しています。

「さまざまなカスタムSQL」の問題を適切に処理するには、多言語永続化フレームワークに目を向けるべきだと思います。アプリケーションが単純なキャッシュに小さなインメモリRDBMSソリューションを使用し、NoSQLソリューションを搭載したマルチテラバイトのデータウェアハウスに書き込むことが判明した場合、標準化されたデータベースインターフェイスの「ソリューション」は神秘的な一般的な方言ではない可能性があります、しかし違いを理解し、適切に処理するよく書かれたフレームワーク。

0
h.j.k.