Usa SQL View o SQL Query?

Question

Sto lavorando a un'applicazione per ottenere dati da un server MS-SQL (2005). Nel testo del comando, posso passare una query SQL come questo:

string query = "SELECT T1.f1, T1.f2, T2.f3 FROM table1 T1 join table2 T2" + 
    "on T1.id = T2.id AND T1.dt = T2.dt ..." 
.... 
cmd.CommandText = query; 

ho potuto anche mettere la query come una vista sul mio server SQL come questo:

CREATE VIEW V1 AS 
    "SELECT T1.f1, ..." 

allora posso utilizzare la vista in una query semplificata come questa:

string query = "SELECT f1, f2, f3 FROM V1"; 
.... 
cmd.CommandText = query; 

Non sono sicuro quale sia la via migliore. La vista sarà più veloce di una query SQL? A proposito, la query che mostro qui è semplificata. La query effettiva SELECT è più complicata.

Answer 1

Vorrei creare una vista per diversi motivi

A) Un punto di vista ben costruito tende per eseguire più velocemente di una query, anche se con l'ottimizzazione delle query si può non notare molta differenza.

B) Mantiene la conoscenza della struttura del database all'interno del database stesso - aggiungendo un buon livello di astrazione (come nota a margine, considerare l'utilizzo di una stored procedure piuttosto che una query inline - questo mantiene anche la conoscenza del database all'interno del database stesso)

C) Se è necessario apportare modifiche strutturali al database, è possibile mantenere la vista coerente senza dover ricostruire il codice.

MODIFICA ho intenzione di modificare questa risposta alla luce di alcuni dei commenti, in modo da chiarire alcuni punti ...

E 'assolutamente vero che una visualizzazione standard non fornisce alcuna reale guadagno di prestazioni su una query. Una visualizzazione standard viene materializzata in fase di runtime, il che non rende sostanzialmente diverso da un modo conveniente per eseguire una query della stessa struttura. Una vista indice, tuttavia, si materializza immediatamente e i risultati vengono mantenuti nell'archiviazione fisica. Come con qualsiasi decisione di progettazione, l'uso di una vista indicizzata dovrebbe essere attentamente considerato. Non c'è il pranzo libero; la penalità che si paga per l'utilizzo delle visualizzazioni indicizzate si presenta sotto forma di requisiti di memoria aggiuntivi e di spese generali associate alla gestione della vista in caso di modifiche al database sottostante.Questi sono i migliori per le istanze di aggregazione e aggregazione complesse di dati di più tabelle e in casi in cui si accede ai dati molto più frequentemente di quanto non sia cambiato.

Concordo anche con i commenti relativi alle modifiche strutturali: l'aggiunta di nuove colonne non influirà sulla visualizzazione. Se, tuttavia, i dati vengono spostati, normalizzati, archiviati, ecc., Può essere un buon modo per isolare tali cambiamenti dall'applicazione. Queste situazioni sono RARA e gli stessi risultati possono essere raggiunti attraverso l'uso di stored procedure piuttosto che una vista.

Answer 2

Oppure è possibile utilizzare una stored procedure. L'utilizzo di un processo memorizzato consentirà a SQL di memorizzare nella cache il piano di esecuzione. Penso che lo stesso sia vero per una visione. Il tuo primo metodo (query ad-hoc) sarà probabilmente il meno efficiente.

Answer 3

La vista è probabilmente una migliore.

In questo modo, è possibile modificare la query (per l'ottimizzazione) in un secondo momento senza dover modificare il codice.

Answer 4

La vista può essere essere più veloce, perché si richiede una stringa di comando più breve, ma la differenza sarà irrilevante.

La vera differenza e il valore di Views, è che come le funzioni e le subroutine, sono riutilizzabili.

Answer 5

Non vi è alcuna differenza di prestazioni (a meno che il testo della query sql sia veramente gigantesco e comporti un costo sul filo).

Answer 6

In generale ho trovato è meglio utilizzare le visualizzazioni per diversi motivi:

• query complesse possono ottenere difficile da leggere nel codice
• È possibile modificare la visualizzazione senza dover ricompilare
• legata a quella , puoi gestire le modifiche nella struttura del database sottostante nella vista senza toccare il codice finché gli stessi campi vengono restituiti

Ci sono probabilmente più motivi, ma a questo punto non scriverei mai una query direttamente nel codice.

Si dovrebbe anche esaminare una specie di tecnologia ORM (Object Relational Mapper) come LINQ to SQL (L2S). Ti consente di utilizzare query simili a SQL nel tuo codice, ma tutto è astratto tramite gli oggetti creati nella finestra di progettazione di L2S.

(In realtà sto spostando i nostri oggetti L2S attuali per scappare dalle viste, in realtà. È un po 'più complicato perché anche le relazioni non vengono passate ... ma mi permette di creare un set di oggetti che funziona su 2 database e mantiene tutto ben estratto, così posso cambiare i nomi delle tabelle sottostanti per correggere le convenzioni di denominazione.)

Answer 7

Il vantaggio delle viste è che è possibile applicare un contesto di sicurezza a queste. Oppure in scenari estremi è possibile utilizzare viste partizionate distribuite per motivi di prestazioni. Altrimenti complicano il controllo delle versioni. Ora devi assicurarti che sia distribuita la versione corretta della vista e la nuova build della tua dll di accesso ai dati.

Ero solito dire che i proc memorizzati erano la strada da percorrere perché sono a) compilati (più veloce) eb) un limite di sicurezza. Nel mondo reale questo è spesso un'ottimizzazione prematura. Il testo del comando SQL inviato dal client è in genere abbastanza efficiente (oltre che più semplice da implementare e distribuire) e il controllo degli accessi a livello di tabella o addirittura l'intero database è adeguato in molti casi.

Answer 8

Le visualizzazioni non sono una funzione di prestazioni. Esistono per ridurre il numero di join e per consentire di denormalizzare senza in realtà denormalizzare.

In altre parole, utilizzare l'opzione che rende il codice il più semplice e non modificare per motivi di prestazioni, a meno che non si abbia il motivo valido per fare ciò . Questi tipi di ottimizzazioni di solito non ne valgono la pena.

Answer 9

A meno che non si inserisca il profilo nel 2 ° paragrafo, si consiglia di evitare le visualizzazioni. Sono ingannevolmente attraenti come un buon modo per astrarre le funzionalità sottostanti. Ma il problema è che una volta che gli sviluppatori iniziano a creare viste, tendono a iniziare a creare viste diverse per ogni possibile combinazione di tabelle e campi, e finisce con un disastro esplosivo non coordinato. Il DBA deve quindi mantenerli tutti perché non c'è modo di dire quali sono effettivamente usati e quali no, e gli sviluppatori finiscono per scrivere i propri join comunque perché è più facile che guadare e capire quale vista esistente è uso.

IMO, l'unica buona ragione per utilizzare le visualizzazioni (e una abbastanza comune) è se il DBA deve avere la libertà di modificare le tabelle sottostanti senza rompere il codice client esistente. Questo è ovviamente possibile solo se quella logica è sul lato DB in una vista o proc. Se ciò si applica a te, vai avanti e usa una vista. Altrimenti, consiglierei un modo diverso di guardare le cose.

Il potere di una vista è l'astrazione che crea. Ma il fatto è che l'astrazione è usata solo dal client, non dal DB stesso. Quindi trovo che sia meglio mettere quell'astrazione sul lato client. Quindi, piuttosto che una vista, basta definire una macro o generatore di stringhe da qualche parte nel codice client che creerà la tua istruzione select per te. Puoi rendere queste semplici all'inizio e progressivamente più complesse man mano che la tua app progredisce. In questo modo manterrai l'astrazione e la riusabilità che una visualizzazione offrirebbe, ma eviterai l'esplosione di visualizzazioni e i colli di bottiglia della comunicazione DBA degli sviluppatori.