16 – 17 -18 views (viste)

Le viste sono delle tabelle virtuali. Quello che viene memorizzato su disco è la query SQL che viene impartita durante la sua creazione.

Creiamo una view con una select che estrae gli italiani dal database Olimpiadi:

CREATE VIEW `Olimpiadi`.`italiani` AS
(select * from nazioni , atleti
where idNazione=nazione and nomeNazione='italia' );

a questo punto mi ritroverò sempre questa tabella virtuale chiamata italiani, che potrò trattare come una tabella vera e propria:

select * from italiani 
where eta < 18;

e ottengo i minorenni dalla views italiani.

Si possono effettuare sulla views tutte le operazioni uguali alle tabelle e oltre alle operazioni SQL anche quelle di rinomina, modifica, drop…

esempi pratici con le views:

selezionare alcune colonne

select cognome, nome from italiani;

fare un ordinamento

select * from italiani order by eta desc

un raggruppamento

select eta, count(*) from italiani 
group by eta

Gli update e i delete con le views sono invece particolari a seconda delle tabelle coinvolte e collegate tra loro e anche le specifiche dei vari dbms.

Inoltre con MySQL è vietato creare una views utilizzando una subquery nella clausola FROM, mentre funziona sul WHERE

CREATE VIEW `Olimpiadi`.`sunquery1` AS 
(select cognome from atleti where eta > (select avg(eta) from atleti) );

Altro limite MySQL è che non è possibile indicizzare una vista mentre con SQL server si mentre con quest’ultimo non si possono usare delle outer join. Per dettagli riferirsi sempre alla documentazione del sistema usato.

Vantaggi nell’utilizzare le view

• Riutilizzo del codice
  con maggiore sicurezza e coerenza, pensare a codice complesso da riutilizzare e ridistribuire

• Maggiore affidabilità
  condividendo la views altri possono testare il codice SQL, migliorarlo o trovare bug o errori, aumentando la qualità
• Vista personalizzata
  pensiamo a database con centinaia di tabelle e migliaia di campi con tante relazioni tra loro, il sistema potrebbe essere molto complesso, ecco che con le views si possono facilitare operazioni e magari usarle solo per alcuni utenti
• Accesso controllato
  Pensate ad una banca, il dbAdmin potrebbe dare accessi diversi a seconda delle operazioni, magari dei privilegi personalizzato per impiegati
• Indipendenza delle applicazioni dalla struttura logica delle tabelle
  consideriamo la classica select cognome, nome, cf … from clienti where … implementata nel codice del programma, un domani si decidesse di cambiare la parte anagrafica da quella fiscale, per esempio, spostare campi da una tabella ad un’altra , ci sarebbero notevoli operazioni di upgrade sulle tabelle fisiche del database. Se invece lo stesso comando l’avessi implementato in una view, andrea semplicemente ad aggiornare la parte di codice della views. Questo è un solo scenario di possibile modifiche dai quali saremmo tutelati.

Le views hanno certamente un limite grosso, non posso chiamarle con dei parametri, cioè non posso passare con una funzione dei paramenti da utilizzare con un where. Se ci fosse una selezione in base ad una faccia di età, dovrei avere tot viste in base alla ciascuna fascia di età, sarebbe bello potere chiamare la views con il parametro età, con le views non è possibile, ma lo è con le stored procedure

b

a

b

a

b

a

b

a

b

a

b

a

b

a

b

a

b

a

b

a

b

a

b

a

b

a

b

a

b

a

b