A cosa servono le visualizzazioni?

Sto solo cercando di avere un'idea generale di quali visualizzazioni vengono utilizzate negli RDBMS. Vale a dire, so cos'è una vista e come crearla. So anche per cosa li ho usati in passato.

Ma voglio assicurarmi di avere una conoscenza approfondita di cosa è utile una vista e per cosa non dovrebbe essere utile. Più specificamente:

1. A cosa serve una vista?
   • Ci sono situazioni in cui si è tentati di usare una vista quando non dovresti usarne una?
   • Perché dovresti usare una vista al posto di qualcosa come una funzione con valori di tabella o viceversa?
   • Ci sono circostanze in cui una vista potrebbe essere utile che non sono evidenti a prima vista?

(E per la cronaca, alcune di queste domande sono intenzionalmente ingenue. Questo è in parte un controllo del concetto.)

1) A cosa serve una vista?

IOPO In One Place Only

• Sia che si considerino i dati stessi o le query che fanno riferimento alle tabelle unite, l'utilizzo di una vista evita ridondanze non necessarie.

• Le viste forniscono anche un livello di astrazione che impedisce l'accesso diretto alle tabelle (e la conseguente manipolazione che fa riferimento alle dipendenze fisiche). In effetti, penso che sia una buona pratica ¹ offrire solo un accesso astratto ai dati sottostanti (utilizzando viste e funzioni con valori di tabella), comprese viste come ¹ Devo ammettere che c'è una buona dose di "Fai come dico; non come fare "in quel consiglio;)

CREATE VIEW AS
      SELECT * FROM tblData

2) Ci sono situazioni in cui si è tentati di usare una vista quando non dovresti usarne una?

Le prestazioni nei join di visualizzazione erano un problema (ad esempio SQL 2000). Non sono un esperto, ma è da un po 'che non me ne preoccupo. (Né riesco a pensare a dove sto attualmente utilizzando i join di visualizzazione.)

Un'altra situazione in cui una visualizzazione potrebbe essere eccessiva è quando la visualizzazione viene referenziata solo da una posizione di chiamata e al suo posto potrebbe essere utilizzata una tabella derivata. Proprio come un tipo anonimo è preferibile a una classe in .NET se il tipo anonimo viene utilizzato / referenziato solo una volta.

    • Vedere la descrizione della tabella derivata in http://msdn.microsoft.com/en-us/library/ms177634.aspx

3) Perché dovresti usare una vista al posto di qualcosa come una funzione con valori di tabella o viceversa?

(A parte i motivi di prestazioni) Una funzione con valori di tabella è funzionalmente equivalente a una vista con parametri. In effetti, un semplice caso d'uso comune di una funzione con valori di tabella consiste semplicemente nell'aggiungere un filtro della clausola WHERE a una vista già esistente in un singolo oggetto.

4) Ci sono circostanze in cui una vista potrebbe essere utile che non sono evidenti a prima vista?

Non riesco a pensare a nessun uso non apparente della parte superiore della mia testa. (Suppongo che se potessi, ciò li renderebbe evidenti;)

In un certo senso, una vista è come un'interfaccia. Puoi cambiare la struttura della tabella sottostante quanto vuoi, ma la vista offre un modo per non dover cambiare il codice.

Le visualizzazioni sono un bel modo per fornire qualcosa di semplice agli scrittori di report. Se i tuoi utenti aziendali desiderano accedere ai dati da qualcosa come Crystal Reports, puoi fornire loro alcune visualizzazioni nel loro account che semplificano i dati, forse anche denormalizzandoli per loro.

Le viste possono essere utilizzate per fornire sicurezza (ad esempio: gli utenti possono avere accesso a viste che accedono solo a determinate colonne in una tabella), le viste possono fornire ulteriore sicurezza per aggiornamenti, inserimenti, ecc. Le viste forniscono anche un modo per alias nomi di colonne (così come sp) ma le visualizzazioni sono più un isolamento dalla tabella effettiva.

In un certo senso le opinioni denormalizzano. La denormalizzazione a volte è necessaria per fornire dati in modo più significativo. Questo è ciò che molte applicazioni fanno comunque tramite la modellazione del dominio nei loro oggetti. Aiutano a presentare i dati in un modo che si avvicina maggiormente alla prospettiva di un'azienda.

Oltre a quanto affermato dagli altri, le viste possono essere utili anche per rimuovere dall'applicazione query SQL più complicate.

Ad esempio, invece che in un'applicazione facendo:

sql = "seleziona a, b da table1 union seleziona a, b da table2";

Potresti astrarlo in una vista:

crea la vista union_table1_table2_v come
seleziona a, b dalla tabella1
unione
seleziona a, b dalla tabella2

e nel codice dell'app, basta avere:

sql = "seleziona a, b da union_table1_table2_v";

Inoltre, se le strutture dei dati cambiano, non sarà necessario modificare il codice dell'app, ricompilare e ridistribuire. cambieresti semplicemente la vista nel db.

Le viste nascondono la complessità del database. Sono ottimi per molte ragioni e sono utili in molte situazioni, ma se hai utenti che sono autorizzati a scrivere le proprie query e rapporti, puoi usarli come protezione per assicurarti che non vengano inviati mal progettati query con fastidiosi join cartesiani che bloccano il server del database.

L'OP ha chiesto se ci fossero situazioni in cui potrebbe essere allettante utilizzare una vista, ma non è appropriato.

Ciò per cui non si desidera utilizzare una vista è un sostituto per join complessi. Cioè, non lasciare che la tua abitudine di programmazione procedurale di scomporre un problema in parti più piccole ti porti a utilizzare più viste unite insieme invece di un'unione più grande. In questo modo si ucciderà l'efficienza del motore di database poiché essenzialmente esegue diverse query separate anziché una più grande.

Ad esempio, supponiamo che devi unire le tabelle A, B, C e D. Potresti essere tentato di creare una vista dalle tabelle A e B e una vista da C & D, quindi unire le due viste insieme. È molto meglio unire A, B, C e D in una query.

Le visualizzazioni possono centralizzare o consolidare i dati. Dove mi trovo abbiamo una serie di database diversi su un paio di server collegati diversi. Ogni database contiene dati per un'applicazione diversa. Un paio di questi database contengono informazioni relative a numerose applicazioni diverse. Quello che faremo in queste circostanze è creare una vista nel database dell'applicazione che si limita a estrarre i dati dal database in cui i dati sono realmente archiviati, in modo che le query che scriviamo non sembrino attraversare database diversi.

Le risposte finora sono corrette: le visualizzazioni sono utili per fornire sicurezza, denormalizzazione (sebbene ci sia molto dolore lungo quella strada se fatto male), astrazione del modello di dati, ecc.

Inoltre, le visualizzazioni sono comunemente utilizzate per implementare la logica di business (un utente scaduto è un utente che non ha effettuato l'accesso negli ultimi 40 giorni, quel genere di cose).

Le viste salvano molte istruzioni JOIN complesse e ripetute negli script SQL. Puoi semplicemente incapsulare un JOIN complesso in una vista e chiamarlo nella tua istruzione SELECT ogni volta che è necessario. Questo a volte sarebbe utile, diretto e più facile che scrivere le istruzioni di join in ogni query.

Una vista è semplicemente un'istruzione SELECT memorizzata. Pensa alle viste come alle funzioni di libreria.

Volevo evidenziare l'uso delle viste per i rapporti. Spesso, esiste un conflitto tra la normalizzazione delle tabelle del database per accelerare le prestazioni, in particolare per la modifica e l'inserimento di dati (usi OLTP), e la denormalizzazione per ridurre il numero di join di tabelle per le query per la creazione di report e l'analisi (usi OLAP). Di necessità, OLTP di solito vince, perché l'immissione dei dati deve avere prestazioni ottimali. La creazione di visualizzazioni, quindi, per prestazioni di reporting ottimali, può aiutare a soddisfare entrambe le classi di utenti (data entry e visualizzatori di report).

Ricordo un SELECT molto lungo che ha coinvolto diversi UNION. Ogni UNION includeva un'unione a una tabella dei prezzi che è stata creata al volo da un SELECT che era di per sé abbastanza lungo e difficile da capire. Penso che sarebbe stata una buona idea avere una visione che per creare la tabella dei prezzi. Avrebbe ridotto la SELECT complessiva di circa la metà.

Non so se il DB valuterà la vista una volta o una volta ogni volta che viene richiamato. Qualcuno sa? Nel primo caso, l'utilizzo di una vista migliorerebbe le prestazioni.

Ogni volta che hai bisogno di [my_interface]! = [User_interface].

Esempio:

TABELLA A:

• id
• Informazioni

VISUALIZZAZIONE per TABELLA A:

• informazioni per il cliente

questo è un modo per nascondere l'id al cliente e rinominare le informazioni con un nome più dettagliato contemporaneamente.

La vista utilizzerà l'indice sottostante per l'ID della chiave primaria, quindi non vedrai una perdita di prestazioni, ma solo una migliore astrazione della query di selezione.