もし私が石油精製所を設計していたとしたら、さまざまなベンダーの材料が微妙ではあるが重要な点で公表された基準に準拠していないとは思いません。あるサプライヤの配管、バルブ、およびその他のコンポーネントは、他のサプライヤの同じ部品と同様に、ANSI 規格に準拠したフランジと肉厚で提供されます。したがって、相互運用性とシステムの安全性が保証されます。
では、なぜ一般的なデータベースは、標準のどの部分に準拠するかについて非常に慎重であり、標準に 100% 準拠したシステムが前面に出ていないのはなぜでしょうか? 標準は「壊れている」か、範囲が不足しているか、設計が難しすぎるか?
これを結論として。SQL の標準を定義する ANSI (または ISO) のポイントは何ですか?
ソフトウェア業界では、実際には標準である標準がいくつかあります。つまり、それらに準拠しない製品は機能しません。ファイル仕様はそのカテゴリに分類されます。しかし、ガイドラインのような「標準」もあります。それらは、ポイントごとの定義を持つ標準として定義される場合がありますが、日常的に部分的にしか実装されていないか、大きな違いがあります。Web 開発は、HTML、CSS、および「ECMAScript」など、さまざまなベンダー (Web ブラウザー) が異なる方法で標準を実装するような「標準」でいっぱいです。
バリエーションは頭痛の種ですが、標準化には依然として利点があります。HTML 標準がまったくなく、各ブラウザが独自のマークアップ言語を使用していたとします。同様に、SQL 標準がなく、各データベース ベンダーが独自の完全に独自のクエリ言語を使用していたとします。ベンダー ロックインがはるかに多くなり、開発者は複数の製品を扱うのが非常に困難になります。
いいえ、ANSI SQL は、ANSI 標準が他の業界で行っているのと同じ目的を果たしません。しかし、それにもかかわらず、それは有用な目的を果たします。
おそらく、標準への準拠は、データベース システムの購入者にとって優先度が低いためです。彼らはより興味を持っています：
いくつかの要因を挙げます。
同じことがプログラミング言語にも当てはまります。現在の ANSI C および C++ 標準のすべての機能をサポートしているコンパイラは (あるとしても) ごくわずかです。
標準にこだわる理由については、ほとんどのベンダーが最終的に標準サポートを搭載しています。たとえば、ほとんどのベンダーは、ほぼすべての SQL89 をサポートしています。これにより、ベンダーはスペック シートの (比較的重要ではない) チェックボックスにチェックを入れることができます。また、私のように移植性の高いコードを書くことに関心のある人は、さまざまな付加機能を省略しなければなりませんが、そうすることができます。
記事「IS SQL A REAL STANDARD ANYMORE?」を参照してください。SQL 標準の現在 (2005 年) の問題についてのディスカッション。
実際、ANSI SQL 標準はあまり守られていません。SOを読んでください：ほとんどのSQLスレッドは標準を参照することはありませんが、たとえば、ネットワークプロトコルに関する議論には、関連するRFCの実際の引用、章、節が含まれることがよくあります。
その理由の 1 つは、SQL 標準が自由に配布できないという事実であると常に考えていました。取得するだけでは簡単ではありません。さまざまな非公式のコピーが浮かんでいます。)
もう 1 つの理由は、非常に複雑なテキストであり、構成が不十分であることです。奇妙な語彙を使用しています (「user」ではなく「authID」など)。標準を理解するためだけに本が必要です (「A guide to the SQL standard」、CJ Date、Hugh Darwen - Addison-Wesley)。
特に ANSI SQL の歴史については知りません。しかし、ソフトウェア開発では、多くの場合、主要なプレーヤーが独自の独自バージョンのものを実装した後に標準が作成されているようです。企業が独自のやり方に投資すると、人々が標準に準拠するためだけに依存するようになった機能を変更または削除することを正当化することは非常に困難です. Web 標準は、この現象の主要な例です。
Mimer SQLは優れた標準サポートを備えていますが、あまり知られていません。主にスウェーデンのいくつかの大規模サイトで生産されています。しかし、多くのサイトが他のサイトに移行していると思います。
詳細なサポート ステートメント:
数年前、パイプとコネクタの相互互換性に関する最悪の業界の 1 つは、消防設備でした。相互に互換性のないホースからポンプへの接続は文字通り数十ありました。相互扶助が消防士の間で一般的になったとき、消防士は機器を相互運用できるようにするために、何十ものアダプターを持ち歩かなければなりませんでした。
9 月 11 日に、警察と消防士の両方が、人々の間で相互通信するためのプライベート ワイヤレス ネットワークを持っていました。しかし、何だと思いますか？2 つのシステムは相互に互換性がありませんでした。そのため、ある種類の公安職員から別の種類の公安職員への情報伝達に不必要な遅延がありました。
十分に遡ると、ニューヨーク市では、配電網の約半分がエジソンが好んだ DC で、残りの半分がウェスティングハウスが好んだ AC だった時期を見つけることができます。
標準は時としてそれ自体で作られ、事実上の標準と呼ばれます。より一般的には、基準は、それを実現するために特に権限を与えられた機関によって設定されなければなりません。SQL 標準に関しては、一部の大手ベンダーは標準よりも前から存在しています。標準に準拠するためには、既存の顧客ベースに利益をもたらさないエンジニアリング費用を投入する必要があります。さらに悪いことに、以前の製品と互換性がなくなる可能性があります。
SQL 標準への完全な準拠はまだ実現する可能性がありますが、可能性は低いです。たとえそうなったとしても、新しい SQL 標準の進化とそれに準拠するまでには遅延時間があります。
HSQLDB のマニュアルによると、最も標準に準拠した RDBMSです。
IMHO、DBベンダーはANSI SQL標準を推進して、ANSIがDBベンダーに「1つの真の方法」を伝えるよりもはるかに多くの新しい機能と構造をその分野に含めています。
DB 市場は、機能、スケーラビリティ、およびコストによって左右されます。ANSI が構文を承認するのを待って、技術的な利点 (つまり、パーティショニング、ピボット、UPSERT、レプリケーション) を放棄して遅らせることは、商業上の優先事項ではありません。それが完了するまでに、独自の構文の重要なインストールが既に行われています。
そうは言っても、ほとんどの DB ベンダーは、ここ数年でコアの「ANSI SQL」サポートを大幅に改善しました。(SELECT FROM INFORMATION_SCHEMA を使用する SQL Server と Oracle の ANSI 結合は、CBO の下でネイティブ結合と同様に実際に機能します)
本当の理由：ほとんどの「開発者」はクライアント中心のコーダーであるため、コッド博士の12の規則を理解も気にもかけていません。これは、重要な意味でリレーショナルデータベースではないMySqlがwebKiddie開発で頻繁に見られる理由でもあります。このような開発者は、基本的なSELECT、UPDATE、DELETEの解析のみを必要とします。彼らはあらゆる種類の制約を避け、「アプリケーションでそれを行う」ことを好みます。反動1960年代のアプリケーションはあなたが得るものです。
企業は通常、互換性のないさまざまなシステムをサポートするジャングルを避けるために、1 つのベンダーを使用する傾向があります。また、3 つの異なるツール セットを使用するよりも、1 つのデータベース ベンダーのツールを使用するように開発者/システム エンジニアをトレーニングする方がはるかに安価です。その後、この会社は、競合他社を買収できるほど大きくなる可能性があります。これは、管理、統合などを行う必要がある別のまったく異なるツール セットを意味します。
それは大変な作業です。
その代わりに、下にあるものを本当に気にしないように、移植性のレイヤーがあると想像してください。それはずっと良いでしょう。