1995年にDate'sとDarwenの「 TheThirdManifesto」が最初に発行されてから、10年以上が経過しました。
今日のデータベースの世界では、リレーショナルスクールの考え方はどこにありますか?マニフェストのアイデアが主流のソフトウェア開発とデータ管理の慣行を変えたという証拠はありますか?彼らは新しいデータ管理製品の作成を促進しましたか?これらの製品は商業的に成功していますか?
1995年にDate'sとDarwenの「 TheThirdManifesto」が最初に発行されてから、10年以上が経過しました。
今日のデータベースの世界では、リレーショナルスクールの考え方はどこにありますか?マニフェストのアイデアが主流のソフトウェア開発とデータ管理の慣行を変えたという証拠はありますか?彼らは新しいデータ管理製品の作成を促進しましたか?これらの製品は商業的に成功していますか?
私は何年にもわたって、OOD が「いつでもすぐに」リレーショナル データベースを追い越すことになっていることについて、多くの議論を見てきました。リレーショナル モデルは過去のものです。巨大なインストールベース(ええと...レガシー)からのその慣性は、OODの進歩を妨げているものです。「『十分』な実装が最終的に登場し、RDBMS の座を奪うことに成功するのは時間の問題です。」
私は決して専門家ではありません。しかし、私はこれについて何度も考えてきましたが、これらの見解は完全に的外れであると信じるようになりました。
ほとんどの「現実世界」のシナリオで重要なのは、データだけです。
プログラミングのテクニック、ツール、言語は変化します。テクノロジーは進化します。企業の「音声応答システム」が大流行し、「ウェブ」の影に隠れてほとんど消えてしまいます。アプリケーションは行き来します。良いものもあれば、そうでないものもあります。重要なものもあれば、単に便利なものもあります。3か月続くものもあれば、30年続くものもあります。しかし、結局のところ、これらすべてのアプリケーションにフィードする情報はシステムの心臓部であり、流行の変動を乗り切らなければなりません。データは残ります。
したがって、「システム」の中核は、データの保持と保護という 1 つの目標を中心に進化する必要があります。
考えてみてください: 特に SQL データベースは、何十年にもわたる実績のある独立した (ほとんど) 標準化されたリポジトリを提供し、時代遅れではなく、本質的に関数型言語でいつでもアクセスできます! これは、最も価値のあるコンポーネントを信頼するのに最適な場所です。
あいまいなストアにデータを保存することを犠牲にして、プログラミング ツール、環境、またはアプリケーションを優先するアプローチ (アプリケーション テクノロジをデータにあまりにも密接にバインドするものはすべて、道に迷う可能性があります)側。
言うまでもありませんが、世界中のすべてのものを SQL テーブルに入れる必要があると私は信じています。OOD のようなソリューションにも場所があり、多くの可能性があります。ただし、「アプリケーション」が王様であり、「データ」が二次的な場所に目を向ける必要があります。たとえば、ゲーム、1 回限りのアプリケーションやツール、重要ではないデータを保持するシステム、過去に長期的な価値がないデータなどです。アプリケーションの寿命。
特に、耐用年数が限られているシステム (せいぜい数年) は、OOD のような技術の最有力候補だと思います。一方、いつの日か後継者にデータを「引き渡す」必要がある作業を行う場合、私は古き良き RDBMS 以外には非常に警戒します。
サウンドバイトで言えば、「アプリケーション」に関するものではありません。それは常に「データ」についてでした。
オブジェクト指向データベースは撞着語です。OOデータベースを作成しようとすればするほど、とにかくリレーショナルの世界にたどり着きます。私の意見では、彼らは単なる誇大広告です。ORMはOOデータベースではないことに注意してください。データセットもそうではありません。私は前にその議論を聞いたので、私は物事を明確にするためだけにそれを言っています。
データを管理するためにオブジェクトモデリングが明らかになるいくつかの方法が見られます。LinqとNHibernateがあり、データベース内のデータをコード内のオブジェクトにマップできます。でも。実際のオブジェクト指向データベースを作成するには、まだ長い道のりがあると思います。私たちがこれまでにそうするかどうかはわかりません。「オブジェクト」を操作することには利点がありますが、リレーショナルデータモデルを使用してデータをセットとして扱うことには多くの利点があります。
これまでのところ、出てきたOODBMSは、一部の人が望んでいたほど広く採用されていないようです。理由は単純です。OODBMSは、OOP開発者の懸念にのみ対処し、DBA、アナリスト、MISを含む他のすべての人には対処しません。専門家、およびオブジェクト指向ではなく、代わりに「データ駆動型」である膨大な数の開発者。
そうは言っても、大量のエンタープライズデータがCOBOL / CICSを利用したシステムにも残っているのと同様に、膨大な量のエンタープライズデータがRDBMSに残っています。
事実については、Googleで何時間も統計を探すことができますが、統計は見つかりません。あなたが見つけるのは、Oracle対MSSQLServer対MySQL/PostGre /その他のオープンソースRDBMS採用統計対相互であり、db4oのようなOODBMSはほとんど無視されます。
ビジネスデータ処理では、リレーショナルモデルがしっかりと定着しており、削除することはできません。それは中心的であり、不適切なことのためにしばしば非常に酷使されています。人々はリレーショナルデータベースを信頼できるメッセージキューとして使用(悪用)します。なぜなら、彼らはすべての問題をデータベースの問題と見なしているからです。
リレーショナルモデルは、すべてのビジネスプロセスの多くの(ほとんどすべての)商用製品のバックボーンです。基本的に関係のないものを見つけるのは難しいです。実際、多くの場合、製品はデータベースと緊密に連携しています。オラクルの財務、マイクロソフトのダイナミクス会計など。
近い将来、リレーショナルデータストアがビジネスデータ処理のプライマリストレージになります。
現在、リレーショナルデータベースは言うまでもありません。誰もが「どのデータベースエンジン」を尋ねるので、Oracle対IBM対Microsoft対MySQLの議論を検討することができます。「データモデルはどうなるのか、オブジェクトかリレーショナルか」という質問は誰もしません。
ORMは引き続き侵入します。オブジェクト指向プログラミングは成長を続け、ますます多くのORMにつながります。ビジネスITはイノベーションではなく安定性に重点を置いているため、この箱から抜け出すのは困難であり、ほぼ不可能です。彼らの目標は、ほとんどの場合「ライトをオンに保つ」です。つまり、ベンダーが廃業するか、製品のサポートを終了することによって変更が強制されるまで、変更を拒否することを意味します。
私は常に大きすぎるデータセットを扱ってきましたが、データをクラスとしてレンダリングする古典的な「オブジェクト」モデルを、それらにアクセス/操作するためのすべての情報とメソッドを含むデータ要素で真剣に検討することはできません。
ただし、.NETデータセットを使用した単純な妥協モデルを見つけました。これらはディスクに「セルフバッファリング」されるため、メモリに収まる場合と収まらない場合があるデータのチャンクを処理するのに最適です。したがって、これらを「オブジェクトコレクション」に使用します。
次に、アプリケーションの「ビジネス」オブジェクトを構成するすべてのクラスは、それらの情報を含むデータセット内のレコードへの参照を持ち、クラスのすべてのメソッドは、レコードセットから単純に解析されます。
基本的にすべてのクラス内部データ変数はレコードセットのフィールドであるため、1つの結果を100万に返すクエリで機能します。クラスモデルは非常に簡単に複製できます。
いいえ 唯一の顕著な変化は、クラウド コンピューティングの出現により、提唱者が必ずしもデータを関連性のある方法で保存するとは限らないごく最近のことです。