Perché i database relazionali funzionano affatto, data la complessità esponenziale teorica della ricerca di risposte (nella dimensione della query)?

Sembra essere noto che per trovare una risposta a una query su un database relazionale D , occorre tempo | D | | Q | e non ci si può liberare dell'esponente | Q | .$Q$$D$$|D|^{|Q|}$$|Q|$

Dato che può essere molto grande, ci chiediamo perché i database funzionino affatto nella pratica.$D$

È solo una questione delle solite query che non sono affatto grandi nelle applicazioni del mondo reale? (Quindi è interessante sapere qual è la dimensione normale delle query poste ai sistemi di database relazionali e qual è la dimensione "massima" delle query che si prevede che in pratica sia effettivamente rispondibile da un sistema DB .)

Note sull'esponente non "rimovibile"$|Q|$

Per dimostrare che l'esponente non è rimovibile, è possibile utilizzare una query che chiede se esiste una cricca di dimensione n nel grafico fornito dal database. Per verificare se un grafico ha un n -clique è un problema NP-completo. Inoltre, non è trattabile a parametro fisso, con parametro n . I dettagli sono disponibili, ad esempio, in Libkin, L .: Elements Of Finite Model Theory. Springer (2004) o Papadimitriou, CH, Yannakakis, M .: Sulla complessità delle query del database. J. Comput. Syst. Sci. 58 (3), 407–427 (1999)$|Q|$$n$$n$$n$

Esistono grandi classi di query che sono "facili", anche nel caso peggiore. In particolare, se la classe di query contiene solo query congiuntive e ogni query ha una larghezza limitata (ad esempio larghezza dell'albero, larghezza dell'albero del suo grafico di incidenza, larghezza ipertestuale frazionaria o larghezza sottomodulare), è possibile rispondere alla query utilizzando qualcosa come un albero di join , insieme all'enumerazione della forza bruta per le parti locali della query che si discostano dall'albero. Ciò richiede tempo polinomiale, con il grado del polinomio determinato dal parametro width.

Sembra che molte domande incontrate nella pratica siano entrambe congiuntive e abbiano una larghezza ridotta. Quindi il runtime polinomiale ha un basso grado in questo caso.

Dániel Marx ha recentemente presentato un documento allo STOC 2010 sulla larghezza sottomodulare, la cui versione completa include un bel riassunto delle varie nozioni di larghezza e di come la formulazione CSP si collega al formalismo del database (la versione della conferenza non lo ha).

• Dániel Marx, Proprietà hypergraph trattabili per soddisfazione dei vincoli e query congiuntive , 2010. arxiv: 0911.0801

Questa non è una risposta completa, poiché non si occupa della complessità "tipica" delle query del database, ma anche con l'analisi del caso peggiore ci sono query facili.

È possibile utilizzare le query Q_n per verificare se un grafico, rappresentato come database, contiene una cricca con n elementi. Controllare se un grafico ha una cricca è un problema NP completo. Inoltre, non è trattabile a parametro fisso, con parametro n (che significa D ^ n).

Un altro modo di rispondere a questa domanda è "non lo fanno!"

Se si assegna a una tipica implementazione DBMS una query contenente un numero molto elevato di join, non supererà nemmeno la fase di pianificazione / ottimizzazione (per non parlare della valutazione), anche se la query è aciclica o ha una struttura molto semplice come András allude a sopra.

Ma, per carichi di lavoro DBMS "tipici", tali query sembrano non sorgere.

Ecco una versione più attenta alla realtà della risposta di tigreen dal punto di vista di una persona che fa un uso intensivo di database (relazionali): il punto e la complessità della loro applicazione è strutturarli in un modo che richiederebbero si unisce per ciascuno e per ogni query sempre più necessario in quanto possibile ed è per questo che in realtà funzionano . In altre parole, non aspettatevi che i database risolvano da soli i problemi complessi - non lo farebbero, ma se usati saggiamente sono uno strumento davvero utile e applicabile.

I join sono solo quadratici rispetto alle relazioni molti-a-molti. Questi sono relativamente rari: in pratica, la maggior parte delle relazioni e dei join sono da 1 a molti, quindi impiegheranno tempo lineare se vengono definiti indici / chiavi. Le query con più join molti-a-molti sono un problema serio.