Le visualizzazioni del database influiscono sulle prestazioni della query?

Question

Le viste del database sono solo un mezzo per semplificare l'accesso ai dati o offrono vantaggi in termini di prestazioni quando si accede alle viste anziché eseguire semplicemente la query su cui si basa la vista? Sospetto che le viste funzionino equamente solo aggiungendo la query di visualizzazione memorizzata a ogni query sui dati della vista, è corretto o ci sono altri dettagli e/o ottimizzazioni?

Answer 1

Dipende dall'RDBMS, ma in genere non è in corso l'ottimizzazione, ed è solo un modo conveniente per semplificare le query. Alcuni sistemi di database utilizzano comunque "viste materializzate", che utilizzano un meccanismo di memorizzazione nella cache.

Answer 2

In genere una visualizzazione è solo un modo per creare una comune abbreviazione per definire i set di risultati di cui avete bisogno frequentemente.

Tuttavia, c'è un lato negativo. La tentazione è quella di aggiungere in ogni colonna che pensi che potresti aver bisogno da qualche parte quando potresti voler usare la vista. Quindi YAGNI viene violato. Non solo colonne, ma a volte join esterni aggiuntivi vengono attaccati "nel caso in cui". Pertanto gli indici di copertura potrebbero non coprire più e il piano di query potrebbe aumentare in termini di complessità (e riduzione dell'efficienza).

YAGNI è un concetto critico nella progettazione SQL.

Answer 3

Ho sempre considerato Views come una stored procedure di sola lettura. Fornisci al database quante più informazioni possibili in anticipo, in modo da poter effettuare la pre-compilazione nel miglior modo possibile.

È possibile indicizzare anche le viste consentendo di accedere a una vista ottimizzata dei dati che si stanno cercando per il tipo di query che si sta eseguendo.

Answer 4

In generale, le visualizzazioni devono essere equivalenti a una query scritta direttamente nelle tabelle sottostanti.

Ma: potrebbero esserci casi di margini e sarà necessario testare il codice. Tutti i moderni sistemi RDBMS dispongono di strumenti che consentono di visualizzare i queryplans e monitorare l'esecuzione. Non prendere la mia (o qualcun altro) parola per questo, quando puoi avere i dati definitivi a portata di mano.

Answer 5

Sebbene una determinata query in esecuzione all'interno di una vista e la stessa query in esecuzione all'esterno della vista si comportino in modo equivalente, le cose diventano molto più complicate rapidamente quando è necessario unire due viste insieme. Si può facilmente finire per portare tabelle che non sono necessarie nella query, o portare tabelle in ridondante. L'ottimizzatore del database potrebbe avere più problemi nella creazione di un buon piano di esecuzione delle query. Quindi, anche se le viste possono essere molto buone in termini di sicurezza più fine e simili, non sono necessariamente buone per la modularità.

Answer 6

So che questo è un thread precedente. La discussione è buona, ma voglio aggiungere un altro pensiero. Le prestazioni dipendono anche da ciò che state utilizzando per estrarre i dati. Ad esempio, se si sta terminando il front-end con qualcosa come Microsoft Access, si può sicuramente ottenere prestazioni per alcune query complesse utilizzando una vista. Ciò è dovuto al fatto che Access non preleva sempre dal server SQL come vorremmo: in alcuni casi trascinerebbe intere tabelle e poi tenterà di elaborare localmente da lì! Non così se usi una vista.

Answer 7

Sì, in tutti i piani di query di tutti i moderni RDBMS (MSSQL dopo il 2005? Ecc.) Vengono memorizzati nella cache eliminando il sovraccarico di pianificazione della query e accelerando le prestazioni rispetto allo stesso SQL eseguito in linea. Precedentemente a questo (e si applica anche alle istruzioni SQL/Preparate parametrizzate), le persone ritenevano che le procedure memorizzate funzionassero meglio.

Molti ancora si aggrappano a questo oggi rendendolo un mito DB moderno. Dal momento che Views/PS ha ottenuto la pianificazione delle query memorizzate nella cache degli SP, sono stati praticamente pari.