Extensión de SQL capturando

Según Immerman , la clase de complejidad asociada con las consultas SQL es exactamente la clase de consultas seguras en $\mathsf{Q(FO(COUNT))}$ (consultas de primer orden más operador de conteo): SQL captura consultas seguras. (En otras palabras, todas las consultas SQL tienen una complejidad en $\mathsf{Q(FO(COUNT))}$ , y todos los problemas en $\mathsf{Q(FO(COUNT))}$ se puede expresar como una consulta SQL.)

En base a este resultado, desde el punto de vista teórico, existen muchos problemas interesantes que pueden resolverse eficientemente pero que no se pueden expresar en SQL. Por lo tanto, una extensión de SQL que sigue siendo eficiente parece interesante. Ésta es mi pregunta:

¿Existe una extensión de SQL (implementado y utilizado en la industria ) que captura $\mathsf{P}$ (es decir, puede expresar todas las consultas computables en tiempo polinómico y ninguna otra)?

Quiero un lenguaje de consulta de base de datos que cumpla con las tres condiciones. Es fácil definir una extensión que se extendería SQL y capturará $\mathsf{P}$ . Pero mi pregunta es si ese lenguaje tiene sentido desde la perspectiva práctica, por lo que quiero un lenguaje que se utilice en la práctica. Si este no es el caso y no existe dicho lenguaje, entonces me gustaría saber si hay una razón que hace que dicho lenguaje no sea interesante desde el punto de vista práctico. Por ejemplo, ¿las consultas que surgen en la práctica suelen ser lo suficientemente simples como para que no haya necesidad de tal lenguaje?

En cuanto a su pregunta principal, recomiendo esto breve encuesta de Martin Grohe.

¿Las consultas que se necesitan en la práctica suelen ser lo suficientemente simples como para que no sea necesario un lenguaje más fuerte?

Diría que esto es válido la mayor parte del tiempo, dada la cantidad justa de extensiones agregadas a los lenguajes de consulta comunes (cierre transitivo, operadores aritméticos, conteo, etc.). Esto proviene del punto de vista de alguien que ha trabajado un poco como desarrollador independiente de sitios web relativamente simples y otras aplicaciones, por lo que no estoy seguro acerca de los usos reales de SQL en industrias más grandes / bases de datos más grandes.

En los raros casos, podría necesitarse un lenguaje más poderoso, supongo que los desarrolladores de software los tratan utilizando el lenguaje en el que escriben la aplicación, no las consultas (como C ++ o Java).

Primero, el poder expresivo de SQL es menos claro de lo que parece. Las características agregadas, de agrupación y aritméticas de SQL resultan tener efectos bastante sutiles. A priori, parece factible que mediante alguna codificación de operadores algebraicos que usen estas características, uno realmente pueda expresar accesibilidad en SQL. Resulta que este no es realmente el caso para SQL-92 , que es "local".

• Leonid Libkin. Potencia expresiva de SQL , TCS 296 (3), 379–404. doi: 10.1016 / S0304-3975 (02) 00736-3 ( preimpresión )

Esto significa que se requiere una extensión para que SQL-92 capture PTIME, y una que permita que el lenguaje resultante sea "no local".

Sin embargo, permitir estructuras ordenadas y con una aritmética limitada de manera realista, demostrar que SQL-92 no puede expresar accesibilidad implicaría que y, por lo tanto, es probable que sea bastante difícil. (Se podría argumentar que siempre existe un orden lineal natural en los tipos de datos en SQL-92, y que, por lo tanto, se podría suponer que las estructuras subyacentes están ordenadas).$\text{TC}^0 \subsetneq \text{NLOGSPACE}$

Luego, el panorama cambió nuevamente, ya que SQL: 1999 (SQL3) incluía recursividad. Entonces, SQL: 1999 parece ser al menos tan expresivo como la lógica de punto fijo con el conteo (aunque creo que los detalles podrían volver a ser bastante complicados, incluida la cuestión del orden). No sé si las nuevas construcciones hicieron que la lógica sea más expresiva de lo que se requiere para capturar PTIME, y sería necesario algún estudio para establecer esto. Mientras tanto, se realizaron nuevas revisiones en 2003 , 2006 , 2008 y 2011(al ser documentos ISO, solo los borradores están disponibles gratuitamente). Estas revisiones agregaron una gran cantidad de nuevas características, incluyendo permitir XQuery como "parte" de las consultas SQL. Supongo que "SQL" ahora es más expresivo de lo que se requiere para capturar PTIME, pero que la codificación requerida para hacerlo podría requerir consultas grandes y poco naturales que podrían no ser compatibles con sistemas reales.

Entonces, creo que hay evidencia de que no hay una extensión industrial de SQL que capture con precisión PTIME , respondiendo a su pregunta de manera difusa. En resumen, las extensiones industriales son bastante potentes y ya pueden haber superado PTIME. Si es cierto que SQL: 1999 ya es lo suficientemente potente como para capturar al menos PTIME, entonces tampoco está claro qué significa realmente "SQL" en su pregunta, ya que uno tendría que definir "SQL" para significar una versión anterior a SQL: 1999

Finalmente, la encuesta de Grohe sobre la búsqueda de lógicas que capturan PTIME (también mencionada por Janoma) indica que no solo capturar PTIME es complicado a menos que tengamos un orden lineal como parte del lenguaje, sino que también sería una prueba de que no podría haber tal lógica. implica .$\text{P} \ne \text{NP}$

• Martin Grohe, La búsqueda de una lógica que capture PTIME , LICS 2008, 267–271. doi: 10.1109 / LICS.2008.11 ( preimpresión )

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

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

$P \ne NP$

$P = NP$

Aunque probablemente no exista para fines reales, seguramente existe y es constructible e implementable. Podría definir ese lenguaje con algo capaz de simular una máquina de Turing hasta un número dado de pasos. IE, capaz de resolver un problema P-completo . Sin embargo, si construye algo así, está casi completo de Turing, excepto por la restricción "dado un número unitario de pasos", que en un lenguaje similar a SQL sería una forma muy extraña de limitarlo a consultas seguras. Podría hacer esto si los pasos son registros de alguna tabla, pero esto todavía no parece nada valioso para fines prácticos.