[SQL] quanto si usano le VISTE (VIEW) nel mondo reale del lavoro?

[dogeht]

come da titolo, mi chiedevo se le viste si usano nel mondo del lavoro.

io ne sento la forte necessità, soprattutto per non far calcolare sempre al database una marea di cose ( visualizzazione scheda autore: libri scritti, ultimo libro scritto, primo libro scritto, autori simili, autori contemporanei, etc... )

ma mi chiedo se e' questa la strada giusta, oppure e' meglio, ad ogni caricamento di pagina, interrogare opportunamente il database.

spero partecipino in tanti alla discussione, mi sembra un argomento cruciale di cui sento parlare poco.

[webus]

Originariamente inviato da dogeht
come da titolo, mi chiedevo se le viste si usano nel mondo del lavoro.

io ne sento la forte necessità, soprattutto per non far calcolare sempre al database una marea di cose ( visualizzazione scheda autore: libri scritti, ultimo libro scritto, primo libro scritto, autori simili, autori contemporanei, etc... )

ma mi chiedo se e' questa la strada giusta, oppure e' meglio, ad ogni caricamento di pagina, interrogare opportunamente il database.

spero partecipino in tanti alla discussione, mi sembra un argomento cruciale di cui sento parlare poco.

io le uso molto ma, forse ho capito male cosa intendi, non è che le viste non interrogano il database. Di fatto agiscono così come se tu inviassi ogni volta una query nel solito modo. A meno che tu ti volessi riferire alle materialized views che però MySQL non supporta ancora. I vantaggi delle viste sono soprattutto semplicità di utilizzo, maggiore sicurezza e manutenzione semplificata.

Per evitare che MySQL interroghi ogni volta fisicamente le tabelle devi ricorre ad altri strumenti, come la cache e gli indici.

[dogeht]

caspita Webus, questo e' un dettaglio importantissimo!

quindi una view ( non "materialized" ) e' semplicemente una scorciatoia testuale per non ripensare delle join completamente daccapo, ma la spesa e' la stessa? (ovviamente ci sono i vantaggi in tema di sicurezza che tu dici)

cmq, come trovato tra i commenti del mysql 5.0 reference (in fondo), un utente conferma cio' che hai detto, dicendo che:

- le viste asservono pienamente alla sicurezza
- le viste sono pesanti quando le select sono frequenti e i dati rimangono piu' o meno gli stessi

in piu' consiglia ( e' una strada rischiosa, direi! ) di simulare le materialized con un robusto update script

[webus]

Una materialized view è solitamente usata in presenza di query dispendiose e dove non è fondamentale che i dati siano aggiornati in tempo reale. In un simile scenario sì, merita prendere in considerazione la soluzione di usare una table fisica da tenere aggiornata periodicamente attraverso triggers o eventi.

Non mi è invece chiaro quel commento sulle view che diventano pesanti quando sono richiamate frequentemente, direi piuttosto il contrario.

La cache conserva i risultati delle query in modo sequenziale (beh, più o meno, ma andremmo fuori tema) per cui l'ultima query servita viene messa in testa alla cache, e lo spazio necessario lo si recupera eliminando quelle via via più vecchie. Va da se quindi che le query che vengono eseguite più spesso avranno più probabilità di essere presenti nella cache, evitando così la scansione fisica delle tabelle o degli indici.

[dogeht]

giusto webus, il meccanismo di cache (che non conoscevo) dovrebbe darti ragione

comincio a comprendere meglio il giusto contesto d'uso per le view, virtuali e materializzate