キャプチャするSQLの拡張

Immermanによると、SQLクエリに関連付けられた複雑度クラスは、（一次クエリとカウント演算子）の安全なクエリのクラスです。SQLは安全なクエリをキャプチャします。（換言すれば、すべてのSQLクエリはで複雑性を有する、そして内のすべての問題 SQLクエリとして表現することができます。）Q （F O （C O U N T ））Q （F O （C O U N T ）$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$

この結果に基づいて、理論的な観点から、効率的に解決できるがSQLでは表現できない興味深い問題が数多くあります。したがって、まだ効率的なSQLの拡張は興味深いようです。だからここに私の質問があります：

をキャプチャするSQLの拡張機能（業界で実装および使用）があり（つまり、すべての多項式時間の計算可能なクエリを表現でき、他のクエリは表現できません）。$\mathsf{P}$

3つの条件をすべて満たすデータベースクエリ言語が必要です。SQLを拡張してをキャプチャする拡張機能を定義するのは簡単です。しかし私の質問は、そのような言語が実際的な観点から理にかなっているかどうかであるので、実際に使用されている言語が欲しいです。これが当てはまらず、そのような言語がない場合、実用的な観点からそのような言語を面白くしない理由があるかどうかを知りたいですか？たとえば、実際に発生するクエリは、通常、そのような言語を必要としないほど単純ですか？$\mathsf{P}$

主な質問については、Martin Groheによるこの短い調査をお勧めします。

実際に必要なクエリは、通常、より強力な言語を必要としないほど単純ですか？

一般的なクエリ言語（推移閉包、算術演算子、カウントなど）にかなりの量の拡張機能が追加されていることを考えると、これはほとんどの場合に当てはまると思います。これは、比較的単純なWebサイトや他のアプリケーションのフリーランス開発者として仕事をした人の観点から来ているので、より大きな産業/より大きなデータベースでのSQLの実際の使用についてはわかりません。

まれに、より強力な言語が必要になる場合がありますが、ソフトウェア開発者は、クエリ（C ++やjavaなど）ではなく、アプリケーションを作成する言語を使用してそれらを処理していると思います。

まず、SQLの表現力は見た目ほど明確ではありません。SQLの集約、グループ化、および算術機能は、非常に微妙な影響を及ぼします。先験的に、これらの機能を使用した代数演算子のエンコードによって、実際にSQLで到達可能性を表現できる可能性があります。これは、実際には「ローカル」であるSQL-92の場合ではないことがわかります。

• レオニード・リブキン。 SQLの表現力、TCS 296（3）、379-404。土井：10.1016 / S0304-3975（02）00736-3（preprint）

これは、PTIMEをキャプチャするためにSQL-92に拡張機能が必要であり、結果の言語を「非ローカル」にできる拡張機能が必要であることを意味します。

しかし、可能規則正しい構造と現実的にSQL-92は、その均一な暗示する到達可能性を表現できないことを証明し、算術限定で、非常に困難であることがありそうです。（SQL-92のデータ型には常に自然な線形順序が存在するため、基礎となる構造が順序付けられていると仮定できると主張できます。）$\text{TC}^0 \subsetneq \text{NLOGSPACE}$

その後、SQL：1999（SQL3）に再帰が含まれていたため、ランドスケープが再び変更されました。したがって、SQL：1999は、少なくともカウントを伴う固定小数点ロジックと同じくらい表現力があるようです（ただし、順序の問題を含め、詳細はやはりややこしいかもしれませんが）。新しいコンストラクトがPTIMEをキャプチャするために必要なロジックをより表現力豊かにしたかどうかはわかりませんが、これを確立するにはいくつかの研究が必要です。その間、2003年、2006年、2008年、2011年にさらなる改訂が行われました。（ISO文書であるため、ドラフトのみが自由に利用できます）。これらの改訂により、XQueryをSQLクエリの「一部」として許可するなど、多数の新機能が追加されました。私の推測では、「SQL」はPTIMEをキャプチャするのに必要な表現よりも表現力が豊かですが、そうするために必要なエンコーディングには、実際のシステムではサポートされない大規模でかなり不自然なクエリが必要になる場合があります。

したがって、PTIMEを正確にキャプチャして、あいまいな方法で質問に答えるSQLの産業拡張がないという証拠があると思います。つまり、産業用拡張機能はかなり強力であり、すでにPTIMEをオーバーシュートしている可能性があります。SQL：1999が少なくともPTIMEをキャプチャするのに十分強力であることが真実である場合、「SQL」がSQLに先行するバージョンを意味するために「SQL」を定義する必要があるため、質問で「SQL」が実際に何を意味するのかも明確ではありません： 1999。

最後に、PTIMEをキャプチャするロジックの検索に関するGroheの調査（Janomaも言及）は、言語の一部として線形順序がない限り、PTIMEをキャプチャするのが難しいだけでなく、そのようなロジックが存在しないという証拠も示されます意味します。$\text{P} \ne \text{NP}$

• Martin Grohe、PTIMEをキャプチャするロジックの探求、LICS 2008、267–271。doi：10.1109 / LICS.2008.11（プレプリント）

$P$$P$$P$$P$$P$

$P = NP$$P = NP$$P$$P$$NPC$

$P \ne NP$

$P = NP$

おそらく実際の目的では存在しませんが、確かに存在し、構築可能で実装可能です。特定の単項ステップまでチューリングマシンをシミュレートできるものでその言語を定義できます。IE、P-complete問題を解決できます。ただし、このようなものを構築する場合、「単項数のステップを与える」制限を除き、チューリング完全です。SQLのような言語では、安全なクエリのみに制限する非常に奇妙な方法です。ステップが何らかのテーブルのレコードである場合、これを行うことができますが、これは実際の目的にとって価値のあるものには見えません。