Quote:
Originariamente inviato da Johnn
In che senso? Quali interrogazioni sarebbero altrimenti impossibili?
|
ti consiglio di prendere un libro qualsiasi di basi di dati (ovviamente a livello universitario) e studiare li questo argomento.
il momento in cui è più evidente che l'uso di viste aumenta il potere espressivo è quando bisognerebbe far uso di operatori aggregati "a cascata"
esempio:
Dipartimento(
cod, nome )
Dipendente(
cod, nome, stipendio, dipartimento* )
(* indica un vincolo di integrità referenziale)
si vuole sapere il codice del dipartimento che spende di più per gli stipendi dei suoi impiegati...
fammi questa query senza usare una vista.
Quote:
|
Sapevo questa cosa e la reputo utile nei casi opportuni. Ma per filosofeggiare un po', una vista materializzata indica una cattiva progettazione del db, no? Teoricamente non si dovrebbe mai arrivare ad usarle!?
|
non vedo perchè una vista materializzata debba indicare cattiva progettazione.
anzi, a volte è proprio per avere una logica il più possibile pulita e ben fatta che l'uso delle viste materializzate diventa comodo.
un esempio stupido ma che dovrebbe farti capire:
decido, per tenere i concetti logici ben separati, di fare una tabella account e una persona, nella prima ci sono solo i dati relativi all'account, nell'altra i dati anagrafici della persona.
da notare che si gestiscono milioni di account, e altrettante persone quindi.
nella pratica, per qualche motivo, ho molto spesso bisogno di riportare i dati dell'utente in maniera completa, quindi riportando sia quelli del suo account che quelli anagrafici, quindi sono costretto a fare un join ogni volta, che costa.
un vista materializzata sarebbe una manna dal cielo, in quanto io farei il join soltanto una volta, e salverei il risultato nella vista, e quindi tutte le volte che dovrei accedere ai dati interrogherei direttamente questa vista, senza bisogno di dover rifare il join ogni volta.
ecco, in questo caso, banalissimo e non così reale, si può già intravvedere che fare una progettazione logica pulita e rigorosa mi ha portato questo piccolo problema, che non ci sarebbe stato se avessi progettato il sistema con un'unica tabella che conteneva sia i dati anagrafici che quelli del proprio account.
Quote:
Ammettiamo che il DBMS supporti i linguaggi procedurali e che le view siano in sola lettura, quindi nessun problema di aggiornamento.
Perché una procedura non potrebbe sostituire una view?
Se la view è basata sulla query X e si mette la stessa query X in una procedura che restuisce i risultati, con in più la possibilità mediante parametri di essere customizzati tramite la clausola WHERE, che differenze ci sono?
Grazie ancora.
|
proprio perchè inserendo la query X nella procedura, questa query verrà rifatta ogni volta, mentre usando una vista materializzata no.
ti ricordo che le procedure sono vantaggiose in quanto, oltre ad aumentare il potere espressivo, vengono compilate una sola volta, mentre le query standard vengono compilate ogni volta.
ma l'esecuzione viene comunque fatta ogni volta.
PS: i problemi delle view non si risolvono rendendole di sola lettura