A cosa servono le visualizzazioni?


87

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
simile alla domanda pubblicata qui: stackoverflow.com/questions/1278521/…
MedicineMan

Ritengo che stackoverflow.com/questions/1278521/… fornisca risposte migliori a questa domanda.
GinTonic

Risposte:


42

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 1 offrire solo un accesso astratto ai dati sottostanti (utilizzando viste e funzioni con valori di tabella), comprese viste come 1 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;)

9
Non sarei d'accordo sul fatto che abbia senso creare una vista su una tabella quando si tratta di un SELECT * FROM tblData. Potete offrire una spiegazione del motivo per cui ciò sarebbe utile?
Utente registrato il

IOPO - In One Place Only - È una frase di design ben nota? Non riesco a trovare molti riferimenti ad esso? Ha altre forme, ad esempio SECCO?
Robert

1
@Robert Sì, DRY, normalizzazione, IOPO, questi sono tutti gusti diversi della stessa filosofia.
TylerH

45

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.


21

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.


18

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.


-1 "viste denormalizzate"? scusa, ma non ha senso a meno che non sia qualificato in qualche modo.
solo qualcuno il

18
Si denormalizzano assolutamente. Se disponi di tabelle correlate normalizzate in terza forma nominale e crei una vista per "appiattire" tale relazione, come è possibile non denormalizzazione?
Kilhoffer

11

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.


Perché dovrei scrivere sql complesso nel database anziché nell'app?
Ivan Virabyan

3
Più la tua query è complicata, più è probabile che cambierà in futuro, in parte a causa del fatto che colpisce più tabelle. Quando le strutture del DB cambiano, dovresti anche cambiare il tuo codice e fare un rilascio. Se tale complessità è astratta in una vista, il DBA potrebbe essere in grado di apportare modifiche strutturali alle tabelle sottostanti senza che il codice debba cambiare.
CodingWithSpike,

11

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.


6

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.


Non penso sia giusto, almeno non è così che va la teoria DBMS (varie implementazioni potrebbero decidere di non onorare la teoria). Il parser di query essenzialmente sostituirà tutte le visualizzazioni che vede con lo sql corrispondente e l'ottimizzatore andrà da lì. I 2 casi dovrebbero essere equivalenti.
SquareCog

Anche questo non è vero quando puoi aggiungere indici alle tue visualizzazioni.
therealhoff

Ho molta familiarità con PostgreSQL e le versioni precedenti non erano molto brave nel combinare le query. Ma quelli più recenti sono molto migliori. La mia risposta non si applica più così tanto, almeno per questo particolare DBMS.
Barry Brown,

5

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.


4

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).


se denormalizzi inserendo in 7 tabelle di riferimento, quindi esegui una query per qualcosa che richiede solo una di quelle tabelle di riferimento. È uno sforzo sprecato. La situazione peggiora se inizi a unirti a tali visualizzazioni.
SquareCog

Sei sicuro di questo? MSDN dice "Quando SQL Server elabora le query che fanno riferimento alle viste in base al nome, le definizioni delle viste normalmente vengono espanse fino a quando non fanno riferimento solo alle tabelle di base. Questo processo è chiamato espansione della vista. È una forma di espansione macro. " Immagino che durante il processo di espansione, il motore sia abbastanza intelligente da includere solo le tabelle sottostanti (della vista) necessarie alla query.
Anthony

Anthony, immagina una query come "select foo_col from (select foo. *, Bar. * From foo join bar on (foo.id = bar.id)". In questa query, la selezione interna è la nostra vista. Non lo è chiaro che il bar join può essere eliminato in sicurezza (infatti se la relazione non è rigorosamente 1-1, non può). Questo diventa ancora più complicato con query più complesse e non consiglierei di fare affidamento sull'RDBMS generico per fare tutto il potare una lattina umana. Forse può farlo SQL Server; sarei scioccato se lo facesse MySQL. Oracle? Postgres? Come sempre, leggi il piano di query in caso di dubbio.
SquareCog

3

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.


2

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


Le stored procedure non sarebbero più adatte a questo? A volte sono necessarie funzioni con visualizzazioni di eliminazioni e aggiornamenti non adatte a questa esigenza. Le visualizzazioni dovrebbero essere considerate come astrazioni o modi per limitare l'utente di destinazione.
HumbleWebDev

1

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).


1

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.


Oracle CBO potrebbe scegliere di valutare la vista una volta (materialize, lo chiamano) o unire l'SQL per la vista nel resto dell'istruzione select ed eseguirla. Deciderebbe in base a cosa aveva il costo stimato inferiore.
WW.

Se l'istruzione select fosse costante per tutta la query e semplicemente ripetuta più volte, un'espressione di tabella comune (CTE) potrebbe risolvere il problema. Ciò si applica solo a SQL Server 2005/2008 poiché non era disponibile in SQL Server 2000. Sì, una visualizzazione sarebbe stata comunque richiamata ripetutamente.
Utente registrato

@ Utente registrato: CTE non è una specialità di SQL Server. Hanno avuto origine in DB2 e sono presenti anche in PostgreSQL (poiché sono utili e nello standard ISO SQL). Se una vista è inline o trattata come una scatola nera dipende dall'implementazione, alcuni RDBMS sono più intelligenti di altri.
solo qualcuno il

@ just somebody: Il mio commento è stato limitato a SQL Server 2005/2008 poiché non ho esperienza con CTE in altri RBDMS. Inoltre, il commento è stato qualificato per indicare che ciò non si applica a SQL Server 2000 poiché le CTE non erano disponibili in SQL Server prima del 2005.
Utente registrato

Un'altra alternativa a una visualizzazione sarebbe stata quella di inserire in anticipo la tabella dei prezzi in una tabella temporanea.
SeaDrive

0

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.