回答検索の理論的な指数関数的な複雑さ（クエリのサイズ）を考えると、なぜリレーショナルデータベースがまったく機能しないのですか？

リレーショナルデータベースでクエリ回答を見つけるには、時間が必要であり、指数を取り除くことができないことがわかっているようです。D | D | | Q | | Q $Q$$D$$|D|^{|Q|}$$|Q|$

非常に大きくなる可能性があるデータベースは、実際にすべてで働いなぜ、我々は疑問に思います。$D$

実際のアプリケーションでは、通常のクエリがまったく大きくないというだけの問題ですか？（その後、リレーショナルデータベースシステムに提示されるクエリの通常のサイズと、実際にDBシステムが効果的に回答できると予想されるクエリの「最大」サイズが何であるかを知ることは興味深いです。）

指数に関する注意事項「取り外し可能」ではない$|Q|$

指数は削除可能ではありません。データベースによって指定されたグラフにサイズnのクリークが存在するかどうかを問い合わせるクエリを使用できます。グラフにnクリークがあるかどうかを確認することは、NP完全問題です。さらに、パラメータnを使用した固定パラメータは扱いやすくありません。詳細については、たとえば、 Libkin、L .: Elements of Finite Model Theoryに記載されています。Springer（2004） または Papadimitriou、CH、Yannakakis、M .:データベースクエリの複雑さについて。J.計算 システム。科学 58（3）、407–427（1999）$|Q|$$n$$n$$n$

最悪の場合でも、「簡単」なクエリの大規模なクラスがあります。特に、クエリのクラスに接続クエリのみが含まれ、各クエリに幅の制限がある場合（たとえば、ツリー幅、その発生グラフのツリー幅、分数ハイパーツリー幅、サブモジュラー幅）、クエリは結合ツリーのようなものを使用して応答できます、ツリーから外れるクエリのローカル部分のブルートフォース列挙。これには、多項式の次数が必要であり、多項式の次数は幅パラメーターによって決定されます。

実際に遭遇する多くのクエリは、接続詞であり、幅が狭いようです。したがって、この場合、多項式ランタイムの次数は低くなります。

DánielMarxは最近、STOC 2010でサブモジュラー幅に関する論文を発表しました。その完全版には、幅のさまざまな概念とCSPの定式化がデータベース形式にどのように関連するかについての素晴らしい要約が含まれています（会議版にはこれがありません）。

• ダニエル・マルクス、制約満足度と接続詞のクエリのための扱いやすいハイパーグラフのプロパティ、2010年arXivの：0911.0801

これは完全な答えではありません。データベースクエリの「典型的な」複雑さを処理しないためです。しかし、最悪の場合の分析でもクエリは簡単です。

クエリQ_nを使用して、データベースとして表されるグラフにn個の要素を持つクリークが含まれているかどうかを確認できます。グラフにクリークがあるかどうかを確認することは、NP完全問題です。さらに、パラメータn（D ^ nを意味する）を使用した固定パラメータは扱いやすくありません。

この質問に答える別の方法は、「彼らはしない！」です。

典型的なDBMS実装に非常に多くの結合を含むクエリを与えると、クエリが非周期的であるか、そうでなければ次のような非常に単純な構造を持っている場合でも、計画/最適化フェーズ（評価は言うまでもありません）を過ぎませんアンドラスは上記を暗示しています。

ただし、「典型的な」DBMSワークロードの場合、このようなクエリは発生しないようです。

以下は、実際に（リレーショナル）データベースを多用する人の観点からのtigreenの回答のより現実に関係するバージョンです。できるだけ一人ひとり常に必要な照会に参加し、その者のなぜ彼ら実際にする仕事。言い換えれば、データベースがあなた自身のために複雑な問題を解決することを期待しないでください-彼らはそうしませんが、賢明に使用された場合、それらは本当に便利で適用可能な手段です。

結合は、多対多のリレーションシップに対して2次のみです。これらは比較的まれです。実際には、ほとんどの関係と結合は1対多であるため、インデックス/キーが定義されている場合は線形の時間がかかります。いくつかの多対多でのクエリは、参加している深刻な問題。