リレーショナル データベースは、さまざまな種類のグラフ (ツリー、有向グラフ、無向グラフなど) を格納するためによく使用されます。
では、主要な DBMS (Microsoft、MySql、Oracle、PostgreSQL、SqlLite など、アルファベット順にいくつか例を挙げると) のどれにも、リレーションをグラフとして扱うためのライブラリ サポートが含まれていないのはなぜでしょうか?
例として、いくつかの望ましい機能:
- 制約チェック (接続性、非循環性、平面性など)
- 一般的に必要な機能 (最短パス、最小全域木、推移閉包、最大フロー/最小カット、クリーク検出、ハミルトニアン/オイラー サイクルなど)
- 上記のいずれかのパフォーマンスを向上させるために必要な補助データ構造
データベースの外部でこれらのいくつかのサポートを構築することは、(他の理由の中でも) 次の理由で複雑です。
- 本質的に複雑です(ライブラリがここで役立ちます)
- 短い答えは多くの場合、多くのデータによってサポートされます。最短パス アルゴリズムを実行している外部クライアントは、データベースと非常に「おしゃべり」する必要があるか、必要以上の量のデータを取得する必要があります。どちらを選択してもネットワークに悪影響を与える
- 整合性がグラフ理論の制約に依存する場合、整合性を維持するには、提案されたすべての更新にアクセスする必要があるため、トリガーが必要であり、トリガーから既存のグラフ ライブラリにアクセスすることは、多くのシステムでは複雑です。
- DBMS ストレージ マネージャーとオプティマイザーは、インデックスの場合と同様に、補助データ構造の問題に対処するために独自に配置されています。
これは修辞的な質問ではありません。興味深い技術的 (または歴史的) な理由があるかどうかを実際に知りたいのです。