Perché crei una vista in un database?

Quando e perché qualcuno decide che è necessario creare una vista nel proprio database? Perché non eseguire semplicemente una stored procedure normale o selezionare?

Una vista offre diversi vantaggi.

1. Le viste possono hide la complessità

Se si dispone di una query che richiede l’unione di più tabelle o una logica complessa o calcoli, è ansible codificare tutta la logica in una vista, quindi selezionare dalla vista proprio 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 e le autorizzazioni impostate sulla vista anziché le tabelle sottostanti. Ciò consente di affiorare solo i dati che un utente deve vedere.

3. Le viste possono semplificare il supporto del codice legacy

Se hai bisogno di rifattorizzare una tabella che rompa un sacco di codice, puoi sostituire la tabella con una vista con lo stesso nome. La vista fornisce lo stesso schema della tabella originale, mentre lo schema attuale è cambiato. Ciò mantiene il codice legacy che fa riferimento alla tabella dalla rottura, permettendoti di cambiare il codice legacy a tuo piacimento.

Questi sono solo alcuni dei molti esempi di come le viste possono essere utili.

Tra le altre cose, può essere usato per la sicurezza. Se hai una tabella “cliente”, potresti voler dare a tutti i tuoi venditori accesso ai campi nome, indirizzo, codice postale, ecc., Ma non credit_card_number. È ansible creare una vista che include solo le colonne a cui è necessario accedere e quindi concedere loro l’accesso sulla vista.

Una vista è un incapsulamento di una query. Le query trasformate in visualizzazioni tendono a essere complicate e in quanto tali salvarle come una vista per il riutilizzo può essere vantaggiosa.

Generalmente creo delle viste per de-normalizzare e / o aggregare i dati usati frequentemente per scopi di reporting.

MODIFICARE

A titolo di elaborazione, se dovessi avere un database in cui alcune delle entity framework erano persona, azienda, ruolo, tipo di proprietario, ordine, dettaglio 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 era incaricato di generare report (o rendere i dati di reporting accessibili ai non sviluppatori) come vendite per dipendente, vendite per cliente o vendite per regione, vendite per mese , clienti per stato, ecc. Creerei un insieme di viste che ha de-normalizzato le relazioni tra le quadro del database in modo tale che fosse disponibile una vista più integrata (nessun gioco di parole) delle quadro del mondo reale. Alcuni dei benefici potrebbero includere:

  1. Riduzione della ridondanza nella scrittura di query
  2. Stabilire uno standard per le quadro correlate
  3. Fornire opportunità di valutare e massimizzare le prestazioni per calcoli e join complessi (es. Indicizzazione su viste Schemabound in MSSQL)
  4. Rendere i dati più accessibili e intuitivi ai membri del team e ai non sviluppatori.

Diversi motivi: se hai complicati join, a volte è meglio avere una vista in modo che ogni accesso abbia sempre i join corretti e gli sviluppatori non debbano ricordare tutte le tabelle 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 hai utenti che vuoi limitare i record che possono mai vedere, puoi usare una vista, dare loro accesso solo alla vista e non alle tabelle sottostanti e quindi interrogare la vista

I report Crystal sembrano preferire l’utilizzo di viste ai processi memorizzati, quindi le persone che scrivono molte segnalazioni tendono a utilizzare molte visualizzazioni

Le viste sono anche molto utili durante il refactoring dei database. Spesso puoi hide la modifica in modo che il vecchio codice non la veda creando una vista. Leggi sui database di refactoring per vedere come funziona in quanto è un modo molto potente per il refactoring.

Il vantaggio principale di una vista su una stored procedure è che è ansible utilizzare una vista proprio come si usa una tabella. Vale a dire, una vista può essere riferita direttamente nella clausola FROM di una query. Ad esempio, SELECT * FROM dbo.name_of_view .

Quasi in ogni altro modo, le stored procedure sono più potenti. Puoi passare i parametri, inclusi out parametri che ti consentono di restituire più valori contemporaneamente, puoi eseguire operazioni SELECT , INSERT , UPDATE e DELETE , ecc. Ecc.

Se vuoi che la capacità di una vista sia di interrogare all’interno della clausola FROM , ma vuoi anche essere in grado di passare i parametri, c’è anche un modo per farlo. Si chiama una funzione valutata a livello di tabella.

Ecco un articolo molto utile sull’argomento:

http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html

EDIT: A proposito, questo tipo di solleva la domanda, quale vantaggio ha una vista su una funzione valutata a livello di tabella? Non ho una risposta molto buona a questo, ma noterò che la syntax T-SQL per la creazione di una vista è più semplice rispetto a una funzione valutata a livello di tabella e gli utenti del database possono avere maggiore familiarità con le visualizzazioni.

Può funzionare come un buon “intermediario” tra il tuo ORM e le tue tabelle.

Esempio:

Avevamo una tabella Persona che ci serviva per modificare la struttura su di essa in modo che la colonna SomeColumn fosse spostata su un’altra tabella e avesse una relazione uno a molti.

Tuttavia, la maggior parte del sistema, per quanto riguarda la Persona, utilizzava ancora SomeColumn come una singola cosa, non molte cose. Abbiamo usato una vista per riunire tutte le SomeColumns e inserirle nella vista, il che ha funzionato bene.

Questo ha funzionato perché il livello dati era cambiato, ma i requisiti aziendali non erano sostanzialmente cambiati, quindi gli oggetti business non avevano bisogno di cambiare. Se gli oggetti aziendali dovessero cambiare non penso che questa sarebbe stata una soluzione praticabile, ma le viste sicuramente funzionano come un buon punto centrale.

Ecco due motivi comuni:

Puoi usarlo per sicurezza. Non concedere autorizzazioni sulla tabella principale e creare viste che limitano l’accesso alla colonna o alla riga e concedere autorizzazioni agli utenti per vedere la vista.

Puoi usarlo per comodità. Unisci insieme alcune tabelle che usi sempre insieme nella vista. Ciò può rendere le query coerenti e più semplici.

C’è più di una ragione per farlo. A volte le query di join comuni sono facili, in quanto è ansible eseguire una query sul nome di una tabella anziché eseguire tutti i join.

Un altro motivo è limitare i dati a diversi utenti. Quindi per esempio:

Table1: Colums – USER_ID; USERNAME; SSN

Gli utenti amministratori possono avere privilegi sulla tabella reale, ma gli utenti a cui non si vuole avere accesso possono dire il SSN, si crea una vista come

 CREATE VIEW USERNAMES COME SELEZIONA user_id, username FROM Table1;

Quindi dai loro dei privilegi per accedere alla vista e non al tavolo.

Le viste possono essere una manna dal cielo quando si fanno report su database legacy. In particolare, puoi usare nomi di tabelle sensoriali invece di nomi di 5 lettere criptate (dove 2 di questi sono un prefisso comune!), O nomi di colonne pieni di abbreviazioni che sono sicuro di avere un senso al momento.

Generalmente vado con le viste per semplificare la vita, ottenere dettagli estesi da parte di alcune quadro archiviate su più tabelle (eliminare molti join nel codice per migliorare la leggibilità) e talvolta condividere i dati su più database o anche per facilitare 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 = 1 

Concentrarsi su visualizzazioni di dati specifici consente 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’utilizzo delle viste per motivi di sicurezza, vedere Utilizzo delle viste come meccanismi di sicurezza.

Semplificare la manipolazione dei dati Le viste possono semplificare il modo in cui gli utenti manipolano i dati. È ansible definire join, proiezioni, query UNION e query SELECT frequentemente utilizzati come visualizzazioni 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, una query complessa utilizzata per la creazione di report e l’esecuzione di subquery, join esterni e aggregazione per recuperare dati da un gruppo di tabelle può essere creata come vista. La vista semplifica l’accesso ai dati perché la query sottostante non deve essere scritta o inviata ogni volta che viene generato il report; la vista è invece interrogata. Per ulteriori informazioni sulla manipolazione dei dati.

È inoltre ansible creare funzioni inline definite dall’utente che operano logicamente come viste parametrizzate o viste che hanno parametri nelle condizioni di ricerca della clausola WHERE. Per ulteriori informazioni, vedere Funzioni definite dall’utente in linea.

Personalizzare le visualizzazioni dei dati consente a diversi utenti di visualizzare i dati in modi diversi, anche quando utilizzano contemporaneamente gli stessi dati. Ciò è particolarmente vantaggioso quando gli utenti con molti interessi e livelli di competenza diversi condividono lo stesso database. Ad esempio, è ansible creare una vista che recuperi solo i dati per i clienti con i quali viene gestito un gestore account. La vista può determinare quali dati recuperare in base all’ID di accesso del gestore account che utilizza la vista.

Per esportare e importare le viste dei dati può essere utilizzato per esportare i dati in altre applicazioni. Ad esempio, è ansible utilizzare i negozi e le tabelle di vendita nel database pubs per analizzare i dati di vendita utilizzando Microsoft® Excel. Per fare ciò, è ansible creare una vista basata sui negozi e sulle tabelle di vendita. È quindi ansible utilizzare l’utilità bcp per esportare i dati definiti dalla vista. I dati possono anche essere importati in determinate viste dai file di dati utilizzando l’utilità bcp o l’istruzione BULK INSERT che fornisce che le righe possano essere inserite nella vista utilizzando l’istruzione INSERT. Per ulteriori informazioni sulle restrizioni per la copia di dati in viste, vedere INSERT. Per ulteriori informazioni sull’utilizzo dell’utilità bcp e dell’istruzione BULK INSERT per copiare dati da e verso una vista, vedere Copia a o da una vista.

Combinare i dati partizionati L’operatore di set UNION Transact-SQL può essere utilizzato all’interno di 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 di vendita per Washington e un’altra tabella contiene dati di vendita per la California, è ansible creare una vista dall’UNION di tali tabelle. La vista rappresenta i dati di vendita per entrambe le regioni. Per utilizzare viste partizionate, si creano diverse tabelle identiche, specificando un vincolo per determinare l’intervallo di dati che è ansible aggiungere a ciascuna tabella. La vista viene quindi creata utilizzando queste tabelle di base. Quando viene interrogata la vista, SQL Server determina automaticamente quali tabelle sono interessate dalla query e fa riferimento solo a tali tabelle. Ad esempio, se una query specifica che sono richiesti solo i dati di vendita per lo stato di Washington, SQL Server legge solo la tabella che contiene i dati di vendita di Washington; non è ansible accedere ad altre tabelle.

Le viste partizionate possono essere basate su dati provenienti da più origini eterogenee, come server remoti, non solo tabelle nello stesso database. Ad esempio, per combinare dati provenienti da diversi server remoti, ciascuno dei quali memorizza i dati per una regione diversa della propria organizzazione, è ansible 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 dalle 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 perché vi sono meno dati da analizzare. Se le tabelle si trovano su server diversi o su un computer con più processori, ciascuna tabella coinvolta nella query può anche essere analizzata in parallelo, migliorando così le prestazioni della query. Inoltre, le attività di manutenzione, come la ricostruzione degli indici o il backup di una tabella, possono essere eseguite più rapidamente. Utilizzando una vista partizionata, i dati appaiono ancora 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 viene soddisfatta una di queste condizioni: Un trigger INSTEAD OF è definito sulla 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, vedere Creazione di una vista partizionata.

https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join

Quando voglio vedere un’istantanea di una tabella (s), e / o visualizzare (in un modo di sola lettura)

Mi piace utilizzare le viste sulle stored procedure quando eseguo solo una query. Le viste possono anche semplificare la sicurezza, possono essere utilizzate per semplificare inserimenti / aggiornamenti su più tabelle e possono essere utilizzate per eseguire snapshot / materializzare i dati (eseguire una query di lunga durata e mantenere i risultati nella cache).

Ho usato le viste materializzate per eseguire query che non richiedono di essere mantenute accurate in tempo reale.

Le viste suddividono anche le configurazioni e le tabelle molto complesse in blocchi gestibili a cui è facile rispondere. Nel nostro database, il nostro intero sistema di gestione delle tabelle è suddiviso in viste da una grande tabella.

Questo non risponde esattamente alla tua domanda, ma ho pensato che valesse la pena di menzionare le Viste materializzate . La mia esperienza è principalmente con Oracle, ma presumibilmente SQL Server è abbastanza simile.

Abbiamo usato qualcosa di simile nella nostra architettura per risolvere problemi di prestazioni XML. I nostri sistemi sono progettati con un sacco di dati memorizzati come XML su una riga e le applicazioni potrebbero aver bisogno di interrogare determinati valori al suo interno. La gestione di molti XMLTypes e l’esecuzione di XPath su un numero elevato di righe ha un notevole impatto sulle prestazioni, pertanto utilizziamo una forma di visualizzazioni materializzate per estrarre i nodes XML desiderati in una tabella relazionale ogni volta che cambia la tabella di base. Ciò fornisce effettivamente un’istantanea fisica della query in un momento specifico rispetto alle viste standard che eseguono la query su richiesta.

Vedo una stored procedure 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 contro cui è ansible creare query o stored procedure. Creerò una vista quando la semplificazione o l’aggregazione ha senso. Scriverò una stored procedure quando voglio fornire un servizio molto specifico.

Una cosa curiosa delle viste è che sono viste da Microsoft Access come tabelle: quando si collega un front-end di Microsoft Access a un database SQL usando ODBC, si vedono le tabelle e le viste nell’elenco delle tabelle disponibili. Pertanto, se si stanno preparando report complicati in MS Access, è ansible consentire al server SQL di partecipare e interrogare e semplificare notevolmente la vita. Idem per la preparazione di una query in MS Excel.

Ho solo 10 o più 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 riscrive che costantemente devo solo chiamare quella vista in una selezione e creare 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.

Pensa a come refactoring lo schema del tuo database.

Penso prima. Per hide la complessità di Query. È molto appropriato per le visualizzazioni. Come quando normalizziamo le tabelle del database aumenta. Ora recuperare i dati è molto difficile quando aumenta il numero di tabelle. Il modo migliore di gestire è seguire le visualizzazioni. Se ho torto correggimi.

Creiamo la vista per limitare o restringere l’accesso a tutte le righe / colonne in una tabella.Se il proprietario vuole che solo le righe / colonne specifiche o limitate debbano essere condivise, allora creerà una vista con quelle colonne.