Domanda

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

Ma voglio assicurarmi di avere una conoscenza approfondita di ciò che una vista è utile e per cui una vista 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 si dovrebbe usare una vista?
    • 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.)

È stato utile?

Soluzione

1) A cosa serve una vista?

IOPO Solo in un unico posto

& # 8226; Sia che tu consideri i dati stessi o le query che fanno riferimento alle tabelle unite, l'utilizzo di una vista evita inutili ridondanze.

& # 8226; Le viste forniscono anche un livello di astrazione che impedisce l'accesso diretto alle tabelle (e le manette risultanti che fanno riferimento a dipendenze fisiche). In effetti, penso che sia buone pratiche 1 offrire solo un accesso astratto ai tuoi dati sottostanti (usando viste e funzioni con valori di tabella), comprese viste come
|
CREA VISUALIZZA COME
& nbsp; & Nbsp; & Nbsp; SELEZIONA * DA tblData


1 Devo ammettere che c'è una buona dose di " Fai come dico; non come faccio " in quel consiglio;)

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

I join delle prestazioni in vista erano un problema (ad es. SQL 2000). Non sono un esperto, ma non mi preoccupo da un po '. (Né riesco a pensare a dove sto attualmente usando i join di vista.

Un'altra situazione in cui una vista potrebbe essere eccessiva è quando si fa riferimento alla vista solo da una posizione di chiamata e si può usare invece una tabella derivata. Proprio come un tipo anonimo è preferibile a una classe in .NET se il tipo anonimo viene utilizzato / referenziato una sola volta.

& nbsp; & Nbsp; & # 8226; Vedi la descrizione della tabella derivata in & nbsp; 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 motivi di prestazioni) Una funzione con valori di tabella è funzionalmente equivalente a una vista con parametri. In effetti, un caso d'uso comune di una semplice funzione valutata a livello di tabella è semplicemente quello di aggiungere un filtro della clausola WHERE a una vista già esistente in un singolo oggetto.

4) Vi 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;)

Altri suggerimenti

In un certo senso, una vista è come un'interfaccia. Puoi modificare la struttura della tabella sottostante tutto ciò che desideri, ma la vista consente di non modificare il codice.

Le viste sono un bel modo di fornire qualcosa di semplice da segnalare agli autori. Se i tuoi utenti aziendali desiderano accedere ai dati da qualcosa come Crystal Reports, puoi dare loro alcune visualizzazioni nel loro account che semplificano i dati, magari addirittura denormalizzarli per loro.

Le viste possono essere utilizzate per fornire sicurezza (ovvero: 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 i nomi delle colonne (come fanno gli sp) ma le viste sono più un isolamento dalla tabella reale.

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

Le viste nascondono la complessità del database. Sono ottimi per molte ragioni e sono utili in molte situazioni, ma se si dispone di utenti autorizzati a scrivere le proprie query e report, è possibile utilizzarli come protezione per assicurarsi che non invii in modo errato query con cattivi join cartesiani che eliminano il tuo server di database.

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

Ad esempio, anziché in un'applicazione che esegue:

  

sql = " seleziona a, b dall'unione table1   seleziona a, b dalla tabella 2 " ;;

Potresti renderlo astratto per una vista:

  

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

e nel codice dell'app, semplicemente:

  

sql = " seleziona a, b da union_table1_table2_v " ;;

Inoltre, se le strutture dati dovessero cambiare, non dovrai cambiare il codice dell'app, ricompilare e ridistribuire. cambieresti semplicemente la vista nel db.

L'OP ha chiesto se c'erano situazioni in cui si poteva essere tentati di usare una vista, ma non è appropriato.

Quello per cui non si desidera utilizzare una vista è un sostituto di join complessi. Ossia, non lasciare che l'abitudine alla programmazione procedurale di suddividere un problema in pezzi più piccoli ti induca a utilizzare diverse viste unite anziché una più grande. In questo modo si annulla l'efficienza del motore di database poiché essenzialmente sta eseguendo diverse query separate anziché una più grande.

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

Le viste possono centralizzare o consolidare i dati. Dove sono, abbiamo un numero di database diversi su un paio di server collegati diversi. Ogni database contiene dati per un'applicazione diversa. Un paio di quei database contengono informazioni relative a diverse applicazioni. Ciò che faremo in tali circostanze è creare una vista nel database di quell'applicazione che tira semplicemente i dati dal database in cui sono realmente archiviati, in modo che le query che scriviamo non sembrino attraversare database diversi.

Le risposte finora sono corrette - le opinioni sono buone per fornire sicurezza, denormalizzazione (anche se c'è molto dolore lungo quella strada se sbagliate), astrazione del modello di dati, ecc.

Inoltre, le viste sono comunemente utilizzate per implementare la logica aziendale (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 ripetute negli script SQL. Puoi semplicemente incapsulare alcuni JOIN complessi in alcune viste e chiamarli nell'istruzione SELECT ogni volta che è necessario. Questo a volte sarebbe utile, diretto e più semplice che scrivere le istruzioni di join in ogni query.

Una vista è semplicemente un'istruzione SELECT memorizzata e denominata. Pensa a visualizzazioni come le funzioni di libreria.

Volevo evidenziare l'uso delle viste per i rapporti. Spesso si verifica 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 delle tabelle per le query di report e analisi (usi OLAP). Per necessità, l'OLTP di solito vince, perché l'immissione dei dati deve avere prestazioni ottimali. La creazione di visualizzazioni, quindi, per prestazioni di report 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 join a una tabella dei prezzi che era stata creata al volo da un SELECT che era piuttosto lungo e difficile da capire. Penso che sarebbe stata una buona idea avere l'idea di creare la tabella dei prezzi. Avrebbe abbreviato la SELEZIONE complessiva di circa la metà.

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

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

Esempio:

TABELLA A:

  • id
  • informazioni

VISUALIZZA per TABELLA A:

  • Informazioni sul cliente

questo è un modo in cui potresti nascondere l'id dal cliente e rinominare le informazioni con un nome più dettagliato in una sola volta.

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top