[database] VIEW in PostgreSQL
Clicca QUI per vedere il messaggio nel forum |
| fabpicca |
Ieri sera a me e a Torak ci è sovvenuto un dubbio. Ma le VIEW di PostgreSQL sono dinamiche o cosa?
Nel senso, una volta creata la VIEW e memorizzata nel DB, se la tabella cui essa attinge viene modificata , la VIEW si modifica di conseguenza o bisogna creare un trigger per ricreare la VIEW ad ogni modifica?
aggiungo: la documentazione di Postgres dice (http://www.postgresql.org/docs/8.1/...createview.html)
[...]CREATE VIEW defines a view of a query. The view is not physically materialized. Instead, the query is run every time the view is referenced in a query.[...]
parrebbe quindi che la query alla base della view venga rieseguita ogniqualvolta si referenzia la query...uhm... |
| torak |
Una vista in questo modo quindi serve quindi per facilitare la scrittura delle select, rendendole più leggibbili (e forse guadagnando qualcosa in termini di caching).
Tuttavia e come se fisicamente postgres rilanciasse la query con cui hai creato la vista ogni volta che le accedi. Questo nel caso di viste non materializzate.
Esistono delle viste dette materializzate che fanno si che il la vista venga in qualche modo scritta su db, e serve per velocizzare l'esecuzione delle query che richiedono spesso quei dati (ad esempio una join costosa può essere memorizzata).
Esistono modi per creare delle viste materializzate anche in postgres (urrahh, ooriah eep!). Lì quando viene effettuato l'aggiornamento si può specificare a seconda della scelta che si effettua (eager, lazy, snapshot, sarcazzo).
Per informazioni serie ->
http://jonathangardner.net/PostgreS...s/matviews.html |
| torak |
come ho scritto bene!
W l'open source
:approved:, by deepblue |
| fabpicca |
| Qualcuno mi sa dire qualcosa dell'effettivo guadango in termini di performance usando le views rispetto alle query effettive? |
| torak |
| scrivi meno quando fai le query, ma in termini di performance a meno che non usi le viste materializzate riesegue la query ogni volta, quindi non guadagni una cippa. |
| Gusher |
Originally posted by fabpicca
Qualcuno mi sa dire qualcosa dell'effettivo guadango in termini di performance usando le views rispetto alle query effettive?
I costi sono i medesimi, come dice torak, ti evita di riscrivere una query magari complessa. IMHO conviene quando devi accedere spesso anche solo ad un sottoinsieme di quella query. Magari hai molti campi, join trà tabelle .. e devi accedere a un solo campo, coviene fare una select sulla view.
Nel caso invece devi eseguire sempre la solita query che hai "storato" tramite una view, forse a queso punto conviene scrivere una stored procedure che tipicamente viene precompilata dal dbms e puoi beneficiarne dal momento che ti ritrovi una grossa mole di dati ed un idicizzazione corretta dei campi. |
| torak |
Non ho mai usato le stored procedure... meglio che mi documenti!
p.s.
ieri sera ho installato postgres 8.1 e ho visto che supporta l'ottimizzazione delle query con algoritmi genetici... azzon... |
| fabpicca |
Originally posted by Gusher
I costi sono i medesimi, come dice torak, ti evita di riscrivere una query magari complessa. IMHO conviene quando devi accedere spesso anche solo ad un sottoinsieme di quella query. Magari hai molti campi, join trà tabelle .. e devi accedere a un solo campo, coviene fare una select sulla view.
Nel caso invece devi eseguire sempre la solita query che hai "storato" tramite una view, forse a queso punto conviene scrivere una stored procedure che tipicamente viene precompilata dal dbms e puoi beneficiarne dal momento che ti ritrovi una grossa mole di dati ed un idicizzazione corretta dei campi.
in effetti quella della stored procedure è una buonissima idea.
Mo ce provo.
intanto mi sono comprato la maglietta di postgresql!
 |
| jdhoring |
Non conosco PostgreSQL.
Nel 99 Oracle (versione 8.1.5) se ne uscì con le "materialized wiew" o "snapshot" in cui la vista è effettivamente materializzataw in una tabella.
La "vista materializzata" viene creata alla creazione della view e può essere "rinfrescata" ad ogni singolo aggiornamento delle base tables, oppure "a tempo".
La sua utilità attiene le prestazioni solo quando una o più base tables si trovano su DB remoti: così si può risparmiare sui tempi di rete; oppure anche in caso di tabelle locali, ad esempio nei casi in cui la snapshot consista di dati frequentemente acceduti (esempio: i movimenti contabili della giornata) con risparmio sui tempi di ricerca in tabelle molto grandi (nel ns. esempio i movimenti contabili degli ultimi 10 anni).
Anche le viste non materializzate hanno i loro perchè, ma raramente attengono alle prestazioni.
Faccio qualche esempio:
1) una query molto complessa, al punto che l'ottimizzatore va in panne ed utilizza un piano di esecuzione inefficiente, ed usata spesso, quindi vale la pena di aggiungere comandi di override rispetto al piano di esecuzione inefficiente...
2) una query che mostra le sole righe che l'utente può vedere e non le altre: do all'utente le grant sulla query, e non sulle tabelle...
3) una query che rende comprensibile agli utenti dei dati molto astratti (ad esempio la base dati di Oracle Designer)... ecc ecc. |
|
|
|
