Erweiterung der SQL-Erfassung

Laut Immerman ist die mit SQL- Abfragen verbundene Komplexitätsklasse genau die Klasse der sicheren Abfragen in (Abfragen erster Ordnung plus ): SQL erfasst sichere Abfragen. (Mit anderen Worten, alle SQL-Abfragen haben eine Komplexität in , und alle Probleme in können als SQL-Abfrage ausgedrückt werden.)$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$

Basierend auf diesem Ergebnis gibt es aus theoretischer Sicht viele interessante Probleme, die effizient gelöst werden können, aber in SQL nicht zum Ausdruck gebracht werden können. Interessant erscheint daher eine noch leistungsfähige Erweiterung von SQL. Also hier ist meine Frage:

Gibt es eine SQL-Erweiterung ( die in der Branche implementiert und verwendet wird ), die erfasst$\mathsf{P}$ (dh alle polynomiell berechenbaren Abfragen und keine anderen ausdrücken kann)?

Ich möchte eine Datenbank-Abfragesprache, die alle drei Bedingungen erfüllt. Es ist einfach, eine Erweiterung zu definieren, die SQL erweitert und . Meine Frage ist jedoch, ob eine solche Sprache aus praktischer Sicht sinnvoll ist, und ich möchte eine Sprache, die in der Praxis verwendet wird. Wenn dies nicht der Fall ist und es keine solche Sprache gibt, würde ich gerne wissen, ob es einen Grund gibt, der eine solche Sprache aus praktischer Sicht uninteressant macht. Sind beispielsweise die in der Praxis auftretenden Fragen in der Regel so einfach, dass eine solche Sprache nicht benötigt wird?$\mathsf{P}$

Was Ihre Hauptfrage betrifft, empfehle ich diese kurze Umfrage von Martin Grohe.

Sind die in der Praxis benötigten Abfragen in der Regel so einfach, dass keine stärkere Sprache benötigt wird?

Ich würde sagen, dass dies die meiste Zeit der Fall ist, da die gängigen Abfragesprachen (transitives Schließen, arithmetische Operatoren, Zählen usw.) ziemlich viele Erweiterungen hinzugefügt haben. Dies kommt aus der Sicht von jemandem, der als freiberuflicher Entwickler relativ einfacher Websites und anderer Anwendungen gearbeitet hat. Daher bin ich mir nicht sicher, wie SQL in größeren Branchen / größeren Datenbanken wirklich eingesetzt wird.

In den seltenen Fällen wird möglicherweise eine leistungsstärkere Sprache benötigt. Ich vermute, dass Softwareentwickler mit ihnen umgehen, indem sie die Sprache verwenden, in der sie die Anwendung schreiben, nicht die Abfragen (wie C ++ oder Java).

Erstens ist die Ausdruckskraft von SQL weniger eindeutig als es scheint. Die Aggregations-, Gruppierungs- und Rechenfunktionen von SQL haben sehr subtile Auswirkungen. A priori scheint es machbar, dass durch eine Codierung von algebraischen Operatoren, die diese Funktionen verwenden, die Erreichbarkeit in SQL ausgedrückt werden kann. Es stellt sich heraus, dass dies bei SQL-92 , das "lokal" ist, nicht der Fall ist.

• Leonid Libkin. Ausdruckskraft von SQL , TCS 296 (3), 379–404. doi: 10.1016 / S0304-3975 (02) 00736-3 ( Vordruck )

Dies bedeutet, dass SQL-92 eine Erweiterung benötigt, um PTIME zu erfassen, und eine Erweiterung, die es der resultierenden Sprache ermöglicht, "nicht lokal" zu sein.

Der Nachweis, dass SQL-92 die Erreichbarkeit nicht ausdrücken kann, wenn geordnete Strukturen und eine realistisch begrenzte Arithmetik zulässig sind, würde jedoch bedeuten, dass einheitlich ist und daher wahrscheinlich recht schwierig ist. (Es könnte argumentiert werden, dass für die Datentypen in SQL-92 immer eine natürliche lineare Reihenfolge besteht und daher angenommen werden kann, dass die zugrunde liegenden Strukturen geordnet sind.)$\text{TC}^0 \subsetneq \text{NLOGSPACE}$

Dann änderte sich die Landschaft erneut, da SQL: 1999 (SQL3) eine Rekursion beinhaltete. SQL: 1999 scheint also mindestens so aussagekräftig zu sein wie die Festkomma-Logik beim Zählen (obwohl ich denke, dass die Details, einschließlich der Frage der Reihenfolge, wieder etwas knifflig sein könnten). Ob die neuen Konstrukte die Logik aussagekräftiger gemacht haben, als es für die Erfassung von PTIME erforderlich ist, weiß ich nicht, und einige Studien wären erforderlich, um dies zu ermitteln. In der Zwischenzeit wurden in den Jahren 2003 , 2006 , 2008 und 2011 weitere Überarbeitungen vorgenommen(Da es sich um ISO-Dokumente handelt, sind nur Entwürfe frei verfügbar.) Diese Überarbeitungen fügten eine ganze Reihe neuer Funktionen hinzu, darunter das Zulassen von XQuery als "Teil" von SQL-Abfragen. Ich vermute, dass "SQL" jetzt aussagekräftiger ist, als es für die Erfassung von PTIME erforderlich ist, aber dass die dazu erforderliche Codierung möglicherweise umfangreiche und ziemlich unnatürliche Abfragen erfordert, die in realen Systemen möglicherweise nicht unterstützt werden.

Es gibt also Anzeichen dafür, dass es keine industrielle Erweiterung von SQL gibt, die PTIME präzise erfasst und Ihre Frage auf unscharfe Weise beantwortet. Kurz gesagt, die industriellen Erweiterungen sind ziemlich leistungsfähig und haben möglicherweise bereits PTIME überschritten. Wenn es stimmt, dass SQL: 1999 bereits leistungsfähig genug ist, um mindestens PTIME zu erfassen, ist auch nicht klar, was "SQL" in Ihrer Frage wirklich bedeutet, da man "SQL" definieren müsste, um eine Version vor SQL zu bezeichnen: 1999.

Schließlich zeigt Grohes Umfrage zur Suche nach Logiken, die PTIME erfassen (ebenfalls von Janoma erwähnt), dass es nicht nur schwierig ist, PTIME zu erfassen, es sei denn, wir haben eine lineare Reihenfolge als Teil der Sprache, sondern auch den Beweis, dass es keine solche Logik geben könnte implizieren .$\text{P} \ne \text{NP}$

• Martin Grohe, Die Suche nach einer Logik, die PTIME erfasst , LICS 2008, 267–271. doi: 10.1109 / LICS.2008.11 ( Preprint )

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

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

$P \ne NP$

$P = NP$

Obwohl es wahrscheinlich nicht für echte Zwecke existiert, existiert es sicherlich und ist konstruierbar und umsetzbar. Sie könnten diese Sprache mit etwas definieren, das eine Turing-Maschine bis zu einer bestimmten Anzahl von Schritten simulieren kann. IE, in der Lage, ein P-vollständiges Problem zu lösen . Wenn Sie jedoch so etwas konstruieren, ist es fast vollständig, bis auf die Einschränkung "bei einer unären Anzahl von Schritten", die in einer SQL-ähnlichen Sprache eine sehr seltsame Art wäre, es auf nur sichere Abfragen zu beschränken. Sie könnten dies tun, wenn die Schritte Aufzeichnungen einer Tabelle sind, aber dies sieht für praktische Zwecke immer noch nicht wertvoll aus.