背景
私は約6年間データベースの設計と開発を行ってきました。 この間、デザインへのアプローチ方法、システムアーキテクチャの選択方法、リレーショナルデータベースを正規化および非正規化するときに存在する機能、特定のデザインとクエリを最適化する方法についてのビジョンを策定しました。 仕事の最初の年に、同じクエリを書くルーチンをやりたくないという結論に達しました。 その結果、独自のストアドプロシージャジェネレータを作成し、データベースの構造により、ほとんどのルーチンクエリを生成しました（興味深い場合は、このトピックに関する記事を作成できます）。 その後、このジェネレーターは年々進化し、最終的に、オブジェクトモデルをリレーショナル構造に変換しないように、オブジェクトをそのまま保存する必要が生じました。 つまり 実際、 ORMアドインを生成するようになりました。 もちろん、十分な数の高品質のORMアドインとオブジェクトリレーショナルデータベースが既に作成されており、それらを正常に使用できると言うことができます（私はあなたに同意しますが、いくつかの予約はあります）。 しかし、それは私にも似合いませんでした。 そして、さらに先へ進むことにしました。
ORMの影響
私の謙虚な意見では、ORMアドオンの使用はOOBDの開発を遅らせるだけです。 このかなり議論の余地のある声明を明確にしようとします。 ORMは悪だとは思いませんが、絶対に良いというわけでもありません。 ORMテクノロジーは、開発ツールの開発において間違いなく重要な役割を果たし（そして今でも）果たしており、プログラマーが実際にデータストレージのロジックを気にかけないことを示しています。 ただし、ここでは、他の場所と同様に「BUT」があります。
ORMを使用すると、間違いなく製品開発がスピードアップし、人件費と何とか何とかが削減されます。 ただし、ORMは、直接作業よりも常に低速に動作する一種のレイヤーです（ここでは、SQLクエリへのすべての呼び出しをアプリケーションに転送することを決して勧めません-至る所に中間点がなければなりません）。 ORMの存在により、開発者はDBMSの作業を実際に考えることができず（ほとんどの場合それを考慮しません）、負荷のかかる最適なアプリケーション操作ではなく、軽度に置く必要があります。 最適化を行うには、レイヤーをクロールし、クエリがより速く動作するように設定する必要があります。データベースをクロールし、インデックスとテーブルを再設定する必要があります。 したがって、アプリケーションが最適に動作するには、ORMがない場合よりも多くの労力が必要です。 その結果、開発コストを削減し、製品の最初のバージョンのリリースを加速しますが、最適化プロセスを複雑にします。
ただし、製品の最初の（そして多くの場合2番目、3番目の）バージョンを作成する時点で最適化について考える人はいません。 現在、ほとんどのオフィスの主な要因は品質ではなく、開発速度です。 それは理解できます。最初は、顧客は最小限のお金を使って、できるだけ早く製品を受け取りたいと思っています。 そしてしばらくしてから、データベースが実際のデータでいっぱいになると、数か月が経過し、顧客（および開発者も）は、サンプリング時間がほぼ2倍になり、10から20人のユーザーが同時に作業し、DBMSが自殺しようとしていることに気付きます。 。 など 開発者は多くの場合、東洋の知恵に導かれます。ロバが死ぬか、スルタンが死ぬか、Khoja自身が死にます。 しかし、誰も死ななかった場合、開発者はボトルネックを探し始め、ORMから自動的に生成されたクエリを削除し、手でそれらを書き換え、データベーステーブルのインデックスを再構築し、この最適化と同様の最適化に多くの時間と労力を費やします。
何かが私を連れ去った。 ORMに対する私の立場を明確に述べたことを願っています。 リレーショナルデータベースとオブジェクト指向データベースの比較（または、必要に応じて）に戻りましょう。
リレーショナルDBとOBOBD
プログラミングでのOOPパラダイムは非常に人気がありますが、このパラダイムはデータベース開発テクノロジーではまだあまり人気がありません。 また、客観的および主観的な理由があります。
- 人気。 保守および開発が必要なリレーショナルデータベース用に、多くの優れた製品が作成されています。 これらの製品にはすでに多くのお金が投資されており、顧客は開発にもっと投資する準備ができています。 対照的に、OOBDを使用して開発された深刻な商用製品は比較的少数であり、強力なOOSBDはほとんどありません。
- クエリ言語とその標準化。 1986年、最初のSQL-86標準が採用され、リレーショナルデータベースの運命が決定されました。 標準の採用後、リレーショナルDBMSのすべての開発者はそれに従う必要がありました。 オブジェクト指向データベースの場合、クエリ言語の標準はまだありません。 現在、開発者の間では、このクエリ言語が行うべきコンセンサスさえありません。
- 数学的装置。 リレーショナルデータベースの場合、 エドガーコッドはかつてリレーショナル代数の数学的装置の基礎を築きました。 このマット。 装置は、データベース内の関係の基本操作をどのように実行するかを説明し、その最適性を証明します（または、最適化する場所から見ることができます）。 一方、この分野での作業は80年代から継続されていますが、ODBDにはこのような装置はありません。 したがって、ODLBには、デカルト積、関係などの厳密な用語はありません。
- データストレージとメソッドの問題。 リレーショナルデータベースは、ベアデータのみを格納します。 アプリケーションがそれらをどのように処理するかは、アプリケーションによって異なります。 反対に、OOBDではオブジェクトを保存する必要があり、オブジェクトはそのプロパティ（オブジェクトパラメーター）とメソッド（オブジェクトインターフェイス）の組み合わせです。 また、ODBDがオブジェクトを保存する方法、および開発者がこれらのオブジェクトを開発および設計する方法についても合意はありません。 これにより、オブジェクトの階層の保存、抽象クラスの保存などの問題も発生します。
結論と展望
開発の世界の現在の状況に照らして、基本的な問題が解決されるまで（マットマシンとクエリ言語の標準）、OOBDを使用した深刻で人気のあるソリューションの見通しは非常に疑わしい（しかし劣らず望ましくない）ようです。 開発者として、これは少し悲しくなります。なぜなら、データベース開発ツールのさらなる定性的な開発には、強力で便利なOOBDの存在が単に必要だという結論に達したからです。
リレーショナルデータベースの展望については、長期にわたって生き続けると思います。 OOBDでは、リレーショナルデータベースを完全に置き換えることはできません。 一部の実際のタスクでは、オブジェクトではなくテーブルにデータを保存する方が便利で正確です。
したがって、時間の経過とともに、OBDBはリレーショナルデータベースから商用システムの市場の一部を取り戻すと考えていますが、リレーショナルデータベースでは現在入手できないような完全な利点を達成しています。