2011-05-06 19 views
13

Esiste una buona pratica generale sull'utilizzo o meno delle viste nidificate? C'è un calo di prestazioni quando si utilizzano viste nidificate? Esiste una best practice che dice che non c'è davvero un successo in termini di prestazioni fino a quando non sei arrivato a 4 o più livelli in profondità?Sql Server 2008 Nidificazione delle viste

Il motivo per cui lo sto chiedendo è perché sono in difficoltà con l'utilizzo o meno di essi. Non è insolito ricevere una richiesta di rapporto di cui l'unico modo per accedere a tali informazioni è unire 20 o più tabelle. I campi non vengono restituiti da tutte le tabelle ma sono necessari per selezionare i dati corretti. In questo caso mi piace annidare le viste e riutilizzare le visualizzazioni di livello inferiore per altri report, perché se è necessaria una modifica alla logica, aggiorno solo una vista e tutti i report vengono aggiornati. Molte delle tabelle con cui lavoro contengono milioni e milioni di record.

Tuttavia, forse questa non è una buona pratica. Ti dispiace condividere i tuoi pensieri su questo?

+2

Le viste fanno aggregazioni? Stai unendo lo stesso tavolo base a se stesso? Guarda il piano di esecuzione e vedi se stai ottenendo piani sub ottimali. –

+0

Potrebbe fornire un esempio di "vista nidificata"? Ho solo familiarità con la terminologia come: vista in linea (tabella derivata AKA), viste non materializzate e materializzate (viste indicizzate AKA in SQL Server). –

+1

@OMG - L'ho preso per significare le viste che fanno riferimento ad altre viste che fanno riferimento ad altre viste ... –

risposta

11

Eviterei questo a tutti i costi. Innanzitutto, una volta annidate le viste, non è possibile indicizzarle. Successivamente, poiché devono materializzare completamente le viste sottostanti per arrivare al livello successivo. Quindi potresti materializzare milioni di record per ottenere un risultato finale di 5 record. Abbiamo quasi perso un cliente da svariati milioni di dollari perché le prestazioni erano talmente abissali quando i nostri sviluppatori lo facevano su un database (non un database che avevo inserito nella progettazione di).

Infine, ho trovato che questo tipo di livelli è molto, molto più difficile da mantenere quando è necessario apportare una modifica. Non è divertente tracciare 12 livelli di visualizzazione per trovare quello che devi correggere. Abbiamo anche riscontrato un problema perché gli sviluppatori trovavano più semplice aggiungere un altro livello che correggere i livelli sottostanti e quindi cercare di accedere a troppe tabelle in una query e troppe di quelle tabelle erano ad accesso alla stessa tabella di record multi-milione 7 o 8 volte in diversi livelli delle viste.

Non c'è alcuna circostanza in cui consentirei più di un livello in una vista in un database che gestisco e sarei arrabbiato se lo facessi.

+2

+1 SQL è una circostanza in cui ripetere se stessi per evitare le visualizzazioni di nidificazione è appropriato. – Matthew

+6

L'ottimizzatore può utilizzare gli indici nelle viste nidificate a meno che la logica della vista non sia complicata e oscuri l'indice. Le viste indicizzate presentano un diverso insieme di problemi, ma per le viste ordinarie che eseguono join semplici, il nesting NON impedisce all'ottimizzatore di utilizzare un indice. –

+0

Voglio dire che non puoi creare indici sulle viste e non che non possono usare indici sottostanti. Tuttavia, è possibile raggiungere rapidamente il punto in cui l'ottimizzatore non riesce a capire come gestirlo in modo efficace. Non solo sono diventati rapidamente un disordine irraggiungibile. È un antipattern di SQL che dovrebbe essere evitato se possibile ed è quasi sempre possibile. – HLGEM

4

Altre opzioni da considerare: Visualizzazioni indicizzate - Può essere pericoloso da utilizzare se non utilizzato correttamente ma i guadagni in termini di prestazioni possono essere sorprendenti.

Analytics - come ad esempio il raggruppamento definisce

procedure & tabelle temporanee - Ottenere i dati necessari tramite procedura di scrivere fuori per tabelle temporanee selezionare da tabelle temporanee.

Nel complesso, non mi piace l'impatto della vista sulle prestazioni sulla vista o sulle viste nidificate.

Generalmente è possibile generare una vista utilizzando i join corretti tra tabelle che contengono tutte le informazioni successive e filtrano i dati utilizzando i criteri.

+0

Domanda relativa alle viste indicizzate. La vista deve essere specificata in modo esplicito o l'ottimizzatore sceglie una vista indicizzata anche se si sta andando su alcune tabelle di base, ma nel percorso di esecuzione determina che la vista è migliore. – user742085

+1

Quindi ho trovato questa risposta La vista non ha bisogno di essere referenziata direttamente nella query affinché l'ottimizzatore la utilizzi nel piano di esecuzione della query. – user742085

+0

@user - Depens on version. Ciò accade solo nella versione Enterprise e Developer altrimenti è necessario fare riferimento alla vista in modo esplicito e utilizzare l'hint 'noexpand'. –

Problemi correlati