Estensione della cattura SQL

Secondo Immerman , la classe di complessità associata alle query SQL è esattamente la classe delle query sicure in $\mathsf{Q(FO(COUNT))}$ (query del primo ordine più operatore di conteggio): SQL acquisisce query sicure. (In altre parole, tutte le query SQL presentano una complessità in $\mathsf{Q(FO(COUNT))}$ e tutti i problemi in $\mathsf{Q(FO(COUNT))}$ può essere espresso come una query SQL.)

Sulla base di questo risultato, dal punto di vista teorico, ci sono molti problemi interessanti che possono essere risolti in modo efficiente ma non sono esprimibili in SQL. Pertanto un'estensione di SQL che è ancora efficiente sembra interessante. Quindi questa è la mia domanda:

Esiste un'estensione di SQL (implementata e utilizzata nel settore ) che acquisisce $\mathsf{P}$ (ovvero può esprimere tutte le query calcolabili in tempo polinomiale e nessun altro)?

Voglio un linguaggio di query del database che risolva tutte e tre le condizioni. È semplice definire un prolungamento che estenderebbe SQL e catturerà $\mathsf{P}$ . Ma la mia domanda è se un tale linguaggio ha senso dal punto di vista pratico, quindi voglio un linguaggio che viene utilizzato nella pratica. Se questo non è il caso e non esiste un linguaggio del genere, allora vorrei sapere se esiste una ragione che rende tale linguaggio poco interessante dal punto di vista pratico? Ad esempio, le domande che sorgono nella pratica di solito sono abbastanza semplici da non rendere necessaria una lingua simile?

Per quanto riguarda la tua domanda principale, ti consiglio questo breve sondaggio di Martin Grohe.

Le domande che sono necessarie nella pratica di solito sono abbastanza semplici da non richiedere un linguaggio più forte?

Direi che questo vale la maggior parte del tempo, data la giusta quantità di estensioni aggiunte ai linguaggi di query comuni (chiusura transitiva, operatori aritmetici, conteggio, ecc.). Questo deriva dal punto di vista di qualcuno che ha svolto un lavoro come sviluppatore freelance di siti Web e altre applicazioni relativamente semplici, quindi non sono sicuro degli usi reali di SQL in settori più grandi / database più grandi.

In rari casi potrebbe essere necessario un linguaggio più potente, suppongo che gli sviluppatori di software li gestiscano utilizzando il linguaggio in cui scrivono l'applicazione, non le query (come C ++ o Java).

Innanzitutto, la potenza espressiva di SQL è meno chiara di quanto sembri. Le caratteristiche aggregate, di raggruppamento e aritmetiche di SQL risultano avere effetti piuttosto sottili. A priori, sembra fattibile che con una certa codifica di operatori algebrici che utilizzano queste funzionalità, si possa effettivamente esprimere la raggiungibilità in SQL. Si scopre che questo non è in realtà il caso di SQL-92 , che è "locale".

• Leonid Libkin. Potenza espressiva di SQL , TCS 296 (3), 379–404. doi: 10.1016 / S0304-3975 (02) 00736-3 ( prestampa )

Ciò significa che è necessaria un'estensione per l'acquisizione di PTIME da parte di SQL-92 e una che consente alla lingua risultante di essere "non locale".

$\text{TC}^0 \subsetneq \text{NLOGSPACE}$

Quindi il panorama è cambiato di nuovo, dal momento che SQL: 1999 (SQL3) includeva la ricorsione. Quindi SQL: 1999 sembra essere almeno espressivo quanto la logica a virgola fissa con il conteggio (anche se penso che i dettagli potrebbero di nuovo essere piuttosto complicati, incluso il problema dell'ordine). Non so se i nuovi costrutti rendessero la logica più espressiva di quanto sia necessario per catturare PTIME, e per stabilire questo sarebbe necessario uno studio. Nel frattempo, nel 2003 , 2006 , 2008 e 2011 sono state apportate ulteriori revisioni(essendo documenti ISO, solo le bozze sono disponibili gratuitamente). Queste revisioni hanno aggiunto tutta una serie di nuove funzionalità, incluso il consentire a XQuery di essere "parte" delle query SQL. La mia ipotesi è che "SQL" ora sia più espressivo di quanto sia necessario per acquisire PTIME, ma che la codifica richiesta per fare ciò potrebbe richiedere query grandi e piuttosto non naturali che potrebbero non essere supportate nei sistemi reali.

Quindi penso che ci siano prove che non esiste un'estensione industriale di SQL che catturi precisamente PTIME , rispondendo alla tua domanda in modo confuso. In breve, le estensioni industriali sono piuttosto potenti e potrebbero già aver superato il PTIME. Se è vero che SQL: 1999 è già abbastanza potente da catturare almeno PTIME, allora non è anche chiaro cosa significhi veramente "SQL" nella tua domanda, dal momento che si dovrebbe definire "SQL" per indicare una versione precedente a SQL: 1999.

Infine, l'indagine di Grohe sulla ricerca di logiche che catturano PTIME (menzionata anche da Janoma) indica non solo che catturare PTIME è complicato a meno che non abbiamo un ordine lineare come parte del linguaggio, ma che una prova che non potrebbe esserci una tale logica sarebbe anche implica .$\text{P} \ne \text{NP}$

• Martin Grohe, La ricerca di una logica che catturi PTIME , LICS 2008, 267–271. doi: 10.1109 / LICS.2008.11 ( prestampa )

La tua domanda non è abbastanza chiaro, se si desidera un'estensione che cattura e solo o se si catturano e possibilmente cose al di fuori . Sembra che tu sia interessante solo nella classe esatta , dal momento che vuoi query sicure e, in caso contrario, qualsiasi estensione di SQL completa di Turing farebbe.P P P $P$$P$$P$$P$$P$

Non sappiamo se . Se , un'estensione SQL in grado di catturare e solo dovrebbe essere in grado di calcolare se una formula booleana è soddisfacente in tempo polinomiale o risolvere qualsiasi altro problema in tempo polinomiale.P = N P P P N P $P = NP$$P = NP$$P$$P$$NPC$

Ma, se , il linguaggio con estensione SQL non sarà in grado di calcolare se una determinata formula booleana è soddisfacente.$P \ne NP$

Quindi, abbiamo una domanda: esistono e algoritmi (o query, o altro) scritti in un linguaggio del genere in grado di decidere se una formula booleana è soddisfacente? Non posso rispondere a questo (e probabilmente nessuno qui può, poiché rispondere a questo è rispondere se ). Questa domanda mi fa credere che è molto improbabile che questo linguaggio esista per scopi reali.$P = NP$

Sebbene probabilmente non esista per scopi reali, esiste sicuramente ed è costruibile e implementabile. Potresti definire quel linguaggio con qualcosa in grado di simulare una macchina di Turing fino a un dato numero unario di passi. IE, in grado di risolvere un problema P-complete . Tuttavia, se costruisci una cosa del genere, è quasi completo di Turing, tranne per la restrizione "dato un numero unario di passaggi", che in un linguaggio simile a SQL sarebbe un modo molto strano di limitarlo solo a query sicure. Potresti farlo se i passaggi sono record di una tabella, ma questo non sembra ancora prezioso per scopi pratici.