.dsy:it. - [database] VIEW in PostgreSQL

.dsy:it. (http://www.dsy.it/forum/)
- Tech (http://www.dsy.it/forum/forumdisplay.php?forumid=189)
-- [database] VIEW in PostgreSQL (http://www.dsy.it/forum/showthread.php?threadid=22844)

Posted by fabpicca on 23-11-2005 08:53:

[database] VIEW in PostgreSQL

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...

__________________
my website?|ubuntu linux|get Firefox|grazie Polonia |bagdad sour

"Come va che non ha le corna e le zampe di Caprone?" gli opposi. "Oh, Giuvà", mi disse il prete "adesso non si usa più.Satana è furbo". (I.Silone, Fontamara)
"Al giorno d'oggi non bisogna essere intelligenti, perchè la gente si offende" (un ubriacone)
"close your eyes / pay the price / for your paradise" (DM) "whatever you want to change/you'd better start changing it in your mind" (Transatlantic)

Posted by torak on 23-11-2005 16:23:

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

Posted by torak on 23-11-2005 16:24:

come ho scritto bene!

W l'open source
:approved: , by deepblue

Posted by fabpicca on 05-12-2005 10:55:

Qualcuno mi sa dire qualcosa dell'effettivo guadango in termini di performance usando le views rispetto alle query effettive?

Posted by torak on 06-12-2005 08:59:

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.

Posted by Gusher on 08-12-2005 08:51:

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.

Posted by torak on 12-12-2005 12:59:

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...

Posted by fabpicca on 12-12-2005 13:23:

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!

Posted by jdhoring on 12-12-2005 13:38:

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.

__________________
Furbo è colui che è molto bravo a togliersi da quei guai in cui il saggio non si sarebbe mai cacciato

Il bravo motociclista è come un buon amante: ha equilibrio, giudizio e tempismo.

Nessuna forma d'amore ha tanto rispetto per la libertà dell'altro come l'amicizia.

All times are GMT. The time now is 09:35.

Show all 9 posts from this thread on one page