Quando e perché qualcuno decide che è necessario creare una vista nel proprio database? Perché non eseguire semplicemente una normale procedura memorizzata o selezionare?
Risposte:
Una vista offre numerosi vantaggi.
1. Le viste possono nascondere la complessità
Se si dispone di una query che richiede l'unione di più tabelle o una logica o calcoli complessi, è possibile codificare tutta quella logica in una vista, quindi selezionare dalla vista come si farebbe con una tabella.
2. Le viste possono essere utilizzate come meccanismo di sicurezza
Una vista può selezionare determinate colonne e / o righe da una tabella (o tabelle) e le autorizzazioni impostate sulla vista anziché sulle tabelle sottostanti. Ciò consente di visualizzare solo i dati che un utente deve vedere.
3. Le viste possono semplificare il supporto del codice legacy
Se è necessario eseguire il refactoring di una tabella che interrompe molto codice, è possibile sostituire la tabella con una vista con lo stesso nome. La vista fornisce lo stesso schema esatto della tabella originale, mentre lo schema effettivo è stato modificato. Ciò impedisce la rottura del codice legacy che fa riferimento alla tabella, consentendoti di modificare il codice legacy a tuo piacimento.
Questi sono solo alcuni dei molti esempi di come le viste possano essere utili.
Tra le altre cose, può essere utilizzato per la sicurezza. Se hai una tabella "cliente", potresti voler dare a tutti i tuoi addetti alle vendite l'accesso ai campi nome, indirizzo, codice postale, ecc., Ma non credit_card_number. È possibile creare una vista che include solo le colonne a cui devono accedere e quindi concedere loro l'accesso alla vista.
Select name, address, zipcode from customernon servirebbe allo scopo invece di creating a view?
select * from customerche consente loro di accedere a tutto. Se si concede loro l'accesso alla vista e non alla tabella, non possono accedere ai campi che non sono presenti nella vista.
Una vista è un incapsulamento di una query. Le query che vengono trasformate in viste tendono ad essere complicate e, in quanto tali, salvarle come viste per il riutilizzo possono essere vantaggiose.
Di solito creo viste per de-normalizzare e / o aggregare i dati usati frequentemente a fini di reportistica.
MODIFICARE
A titolo di elaborazione, se avessi un database in cui alcune delle entità erano persona, azienda, ruolo, tipo di proprietario, ordine, dettagli dell'ordine, indirizzo e telefono, dove la tabella delle persone memorizzava sia i dipendenti che i contatti e l'indirizzo e le tabelle telefoniche memorizzavano i numeri di telefono sia per le persone che per le aziende, e il team di sviluppo aveva il compito di generare report (o rendere i dati dei report accessibili ai non sviluppatori) come vendite per dipendente o vendite per cliente o vendite per regione, vendite per mese , clienti per stato, ecc. Vorrei creare una serie di viste che hanno normalizzato le relazioni tra le entità del database in modo che fosse disponibile una vista più integrata (nessun gioco di parole) delle entità del mondo reale. Alcuni dei vantaggi potrebbero includere:
Diverse ragioni: se si hanno join complicati, a volte è meglio avere una vista in modo che ogni accesso abbia sempre i join corretti e gli sviluppatori non devono ricordare tutti i tavoli di cui potrebbero aver bisogno. In genere questo potrebbe essere per un'applicazione finanziaria in cui sarebbe estremamente importante che tutti i report finanziari siano basati sullo stesso set di dati.
Se si dispone di utenti che si desidera limitare i record che possono mai vedere, è possibile utilizzare una vista, dare loro accesso solo alla vista e non alle tabelle sottostanti, quindi interrogare la vista
I report Crystal sembrano preferire utilizzare le visualizzazioni per i processi memorizzati, quindi le persone che scrivono molti report tendono a utilizzare molte visualizzazioni
Le viste sono anche molto utili per il refactoring dei database. Spesso puoi nascondere la modifica in modo che il vecchio codice non la veda creando una vista. Leggi i database di refactoring per vedere come funziona in quanto è un modo molto potente di refactoring.
L'unico vantaggio principale di una vista rispetto a una procedura memorizzata è che è possibile utilizzare una vista proprio come si usa una tabella. Vale a dire, è possibile fare riferimento a una vista direttamente nella FROMclausola di una query. Ad es SELECT * FROM dbo.name_of_view.
In quasi tutti gli altri modi, le stored procedure sono più potenti. È possibile passare in parametri, tra cui outi parametri che consentono effettivamente di restituire più valori in una sola volta, si può fare SELECT, INSERT, UPDATE, e DELETEle operazioni, ecc ecc
Se si desidera che una vista sia in grado di eseguire query all'interno della FROMclausola, ma si desidera anche poter passare parametri, esiste anche un modo per farlo. Si chiama funzione con valori di tabella.
Ecco un articolo piuttosto utile sull'argomento:
EDIT: A proposito, questo tipo di domanda solleva la domanda, che vantaggio ha una vista rispetto a una funzione valutata a livello di tabella? Non ho una buona risposta a questo, ma noterò che la sintassi T-SQL per la creazione di una vista è più semplice rispetto a una funzione con valori di tabella e gli utenti del database potrebbero avere più familiarità con le viste.
Può funzionare come un buon "intermediario" tra il tuo ORM e i tuoi tavoli.
Esempio:
Avevamo una tabella Person di cui avevamo bisogno per cambiare la struttura su di essa in modo che la colonna SomeColumn sarebbe stata spostata su un'altra tabella e con una relazione da una a molte.
Tuttavia, la maggior parte del sistema, per quanto riguarda la Persona, utilizzava ancora SomeColumn come un'unica cosa, non molte cose. Abbiamo usato una vista per riunire tutte le SomeColumns e metterle nella vista, che ha funzionato bene.
Ciò ha funzionato perché il livello dati era cambiato, ma i requisiti aziendali non erano sostanzialmente cambiati, quindi gli oggetti business non dovevano cambiare. Se gli oggetti business dovessero cambiare, non credo che questa sarebbe stata una soluzione praticabile, ma le viste funzionano sicuramente come un buon punto intermedio.
Concentrarsi su dati specifici Le viste consentono agli utenti di concentrarsi su dati specifici che li interessano e sulle attività specifiche di cui sono responsabili. I dati non necessari possono essere lasciati fuori dalla vista. Ciò aumenta anche la sicurezza dei dati perché gli utenti possono vedere solo i dati definiti nella vista e non i dati nella tabella sottostante. Per ulteriori informazioni sull'uso delle viste per motivi di sicurezza, consultare Uso delle viste come meccanismi di sicurezza.
Semplificare la manipolazione dei dati Le viste possono semplificare il modo in cui gli utenti manipolano i dati. È possibile definire join, proiezioni, query UNION e query SELECT utilizzati di frequente in modo che gli utenti non debbano specificare tutte le condizioni e le qualifiche ogni volta che viene eseguita un'operazione aggiuntiva su tali dati. Ad esempio, è possibile creare come vista una query complessa utilizzata a scopo di report ed eseguire sottoquery, join esterni e aggregazioni per recuperare dati da un gruppo di tabelle. La vista semplifica l'accesso ai dati perché la query sottostante non deve essere scritta o inviata ogni volta che viene generato il rapporto; la vista viene invece interrogata. Per ulteriori informazioni sulla manipolazione dei dati.
È inoltre possibile creare funzioni incorporate definite dall'utente che operano logicamente come viste con parametri o viste con parametri nelle condizioni di ricerca della clausola WHERE. Per ulteriori informazioni, consultare Funzioni incorporate definite dall'utente.
Per personalizzare i dati consentono a diversi utenti di visualizzare i dati in modi diversi, anche quando utilizzano gli stessi dati contemporaneamente. Ciò è particolarmente vantaggioso quando gli utenti con interessi e livelli di competenza diversi condividono lo stesso database. Ad esempio, è possibile creare una vista che recupera solo i dati per i clienti con cui gestisce un account manager. La vista può determinare quali dati recuperare in base all'ID di accesso dell'account manager che utilizza la vista.
Per esportare e importare dati viste possono essere utilizzate per esportare dati in altre applicazioni. Ad esempio, potresti voler utilizzare i negozi e le tabelle delle vendite nel database dei pub per analizzare i dati di vendita utilizzando Microsoft® Excel. Per fare ciò, è possibile creare una vista basata sui negozi e sulle tabelle delle vendite. È quindi possibile utilizzare l'utilità bcp per esportare i dati definiti dalla vista. I dati possono anche essere importati in determinate viste da file di dati usando l'utilità bcp o l'istruzione BULK INSERT a condizione che le righe possano essere inserite nella vista usando l'istruzione INSERT. Per ulteriori informazioni sulle restrizioni per la copia dei dati nelle viste, vedere INSERISCI. Per ulteriori informazioni sull'uso dell'utilità bcp e dell'istruzione BULK INSERT per copiare dati da e verso una vista, vedere Copia da o da una vista.
Per combinare i dati partizionati L'operatore del set UNION Transact-SQL può essere utilizzato in una vista per combinare i risultati di due o più query da tabelle separate in un singolo set di risultati. Questo appare all'utente come una singola tabella chiamata vista partizionata. Ad esempio, se una tabella contiene dati sulle vendite per Washington e un'altra tabella contiene dati sulle vendite per la California, è possibile creare una vista dall'UNIONE di tali tabelle. La vista rappresenta i dati di vendita per entrambe le regioni. Per utilizzare le viste partizionate, creare diverse tabelle identiche, specificando un vincolo per determinare l'intervallo di dati che è possibile aggiungere a ciascuna tabella. La vista viene quindi creata usando queste tabelle di base. Quando viene eseguita la query sulla vista, SQL Server determina automaticamente quali tabelle sono interessate dalla query e fa riferimento solo a tali tabelle. Per esempio, se una query specifica che sono richiesti solo i dati di vendita per lo stato di Washington, SQL Server legge solo la tabella contenente i dati di vendita di Washington; non è possibile accedere ad altre tabelle.
Le viste partizionate possono essere basate su dati provenienti da più fonti eterogenee, come server remoti, non solo tabelle nello stesso database. Ad esempio, per combinare i dati da diversi server remoti, ognuno dei quali memorizza i dati per una diversa regione dell'organizzazione, è possibile creare query distribuite che recuperano i dati da ciascuna origine dati e quindi creare una vista basata su tali query distribuite. Qualsiasi query legge solo i dati delle tabelle sui server remoti che contengono i dati richiesti dalla query; gli altri server a cui fanno riferimento le query distribuite nella vista non sono accessibili.
Quando si partizionano i dati su più tabelle o più server, le query che accedono solo a una frazione dei dati possono essere eseguite più rapidamente poiché vi sono meno dati da scansionare. Se le tabelle si trovano su server diversi o su un computer con più processori, ogni tabella coinvolta nella query può anche essere scansionata in parallelo, migliorando così le prestazioni della query. Inoltre, le attività di manutenzione, come la ricostruzione di indici o il backup di una tabella, possono essere eseguite più rapidamente. Utilizzando una vista partizionata, i dati vengono comunque visualizzati come una singola tabella e possono essere interrogati come tali senza dover fare riferimento manualmente alla tabella sottostante corretta.
Le viste partizionate sono aggiornabili se si verifica una di queste condizioni: Un trigger INSTEAD OF è definito nella vista con la logica per supportare le istruzioni INSERT, UPDATE e DELETE.
Sia la vista che le istruzioni INSERT, UPDATE e DELETE seguono le regole definite per le viste partizionate aggiornabili. Per ulteriori informazioni, consultare Creazione di una vista partizionata.
https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join
Ecco due motivi comuni:
Puoi usarlo per sicurezza. Non concedere autorizzazioni sulla tabella principale e creare viste che limitano l'accesso a colonne o righe e concedere autorizzazioni agli utenti per visualizzare la vista.
Puoi usarlo per comodità. Unisci alcuni tavoli che usi insieme nella vista. Ciò può rendere le query coerenti e più semplici.
C'è più di un motivo per farlo. A volte rende semplici le query di join comuni in quanto si può semplicemente interrogare il nome di una tabella invece di eseguire tutti i join.
Un altro motivo è limitare i dati a diversi utenti. Quindi per esempio:
Tabella 1: colonne - USER_ID; USERNAME; SSN
Gli utenti amministratori possono disporre di priv sulla tabella effettiva, ma gli utenti a cui non si desidera avere accesso per dire l'SSN, si crea una vista come
CREA VISUALIZZA USERNAMES COME SELEZIONA user_id, nome utente DA Table1;
Quindi dai loro i privilegi per accedere alla vista e non alla tabella.
Le visualizzazioni possono essere una manna dal cielo quando si effettuano report su database legacy. In particolare, puoi usare nomi di tabella sensuali invece di nomi di 5 lettere criptici (dove 2 di questi sono un prefisso comune!), O nomi di colonne pieni di abbreviazioni che sono sicuramente sensate in quel momento.
In genere vado con le viste per semplificare la vita, ottenere dettagli estesi da alcune entità archiviate su più tabelle (eliminare un sacco di join nel codice per migliorare la leggibilità) e talvolta per condividere dati su più database o persino per rendere più facile la lettura degli inserti.
Ecco come utilizzare una vista insieme alle autorizzazioni per limitare le colonne che un utente può aggiornare nella tabella.
/* This creates the view, limiting user to only 2 columns from MyTestTable */
CREATE VIEW dbo.myTESTview
WITH SCHEMABINDING AS
SELECT ID, Quantity FROM dbo.MyTestTable;
/* This uses the view to execute an update on the table MyTestTable */
UPDATE dbo.myTESTview
SET Quantity = 7
WHERE ID = 1Quando voglio vedere un'istantanea di una tabella (e) e / o vista (in un modo di sola lettura)
Mi piace utilizzare le viste sulle procedure memorizzate quando eseguo solo una query. Le viste possono anche semplificare la sicurezza, possono essere utilizzate per facilitare inserimenti / aggiornamenti su più tabelle e possono essere utilizzate per eseguire uno snapshot / materializzare i dati (eseguire una query di lunga durata e mantenere i risultati memorizzati nella cache).
Ho usato viste materializzate per query di esecuzione che non sono richieste per essere mantenute accurate in tempo reale.
Questo non risponde esattamente alla tua domanda, ma ho pensato che valesse la pena menzionare Viste materializzate . La mia esperienza è principalmente con Oracle, ma presumibilmente SQL Server è abbastanza simile.
Abbiamo usato qualcosa di simile nella nostra architettura per affrontare i problemi di prestazioni XML. I nostri sistemi sono progettati con molti dati archiviati come XML su una riga e le applicazioni potrebbero dover interrogare valori particolari al suo interno. La gestione di molti tipi XML e l'esecuzione di XPath su un gran numero di righe ha un grande impatto sulle prestazioni, quindi utilizziamo una forma di viste materializzate per estrarre i nodi XML desiderati in una tabella relazionale ogni volta che la tabella di base cambia. Ciò fornisce effettivamente un'istantanea fisica della query in un determinato momento rispetto alle viste standard che eseguono la query su richiesta.
Vedo una procedura memorizzata più come un metodo che posso chiamare contro i miei dati, mentre per me una vista fornisce un meccanismo per creare una versione sintetica dei dati di base sulla quale è possibile creare query o procedure memorizzate. Creerò una visione quando la semplificazione o l'aggregazione avranno senso. Scriverò una procedura memorizzata quando voglio fornire un servizio molto specifico.
Una cosa curiosa delle visualizzazioni è che vengono visualizzate da Microsoft Access come tabelle: quando si collega un front-end di Microsoft Access a un database SQL tramite ODBC, le tabelle e le visualizzazioni vengono visualizzate nell'elenco delle tabelle disponibili. Quindi, se stai preparando report complicati in MS Access, puoi consentire al server SQL di eseguire l'unione e le query e semplificare notevolmente la tua vita. Idem per la preparazione di una query in MS Excel.
Ho solo circa 10 visualizzazioni nei miei database di produzione. Ne uso diversi per le colonne che uso sempre. Un set che utilizzo proviene da 7 tabelle, alcune con join esterni e piuttosto che riscrivere che costantemente devo solo chiamare quella vista in una selezione ed effettuare uno o 2 join. Per me è solo un risparmio di tempo.
Sto creando xxx che mappa tutte le relazioni tra una tabella principale (come la tabella Prodotti) e le tabelle di riferimento (come ProductType o ProductDescriptionByLanguage). Questo creerà una vista che mi permetterà di recuperare un prodotto e tutti i suoi dettagli tradotti dalle sue chiavi esterne alla sua descrizione. Quindi posso usare un ORM per creare oggetti per creare facilmente griglie, caselle combinate, ecc.
Pensalo come un refactoring dello schema del tuo database.
Penso al primo. Per nascondere la complessità di Query. È molto appropriato per le visualizzazioni. Come quando aumentiamo le tabelle del database. Ora è molto difficile recuperare i dati quando aumenta il numero di tabelle. Il modo migliore per gestire è seguire le visualizzazioni. Se sbaglio correggimi.
Creiamo una vista per limitare o limitare l'accesso a tutte le righe / colonne in una tabella. Se il proprietario desidera che solo le righe / colonne specifiche o limitate debbano essere condivise, creerà una vista con quelle colonne.
Per motivi di sicurezza: concede a ciascun utente l'autorizzazione ad accedere al database solo attraverso un piccolo set di visualizzazioni che contengono i dati specifici che l'utente o il gruppo di utenti è autorizzato a vedere, limitando l'accesso degli utenti ad altri dati.
Semplicità per query e struttura : una vista può disegnare dati da più tabelle e presentare una singola tabella, semplificando le informazioni e trasformando query a più tabelle in query a tabella singola per una vista e offre agli utenti una vista specifica della struttura del database, presentando il database come un insieme di tabelle virtuali specifiche per utenti o gruppi di utenti specifici.
Per creare una struttura di database coerente : le viste presentano un'immagine coerente e invariata della struttura del database, anche se vengono modificate le tabelle di origine sottostanti.