.dsy:it. (http://www.dsy.it/forum/)
- Basi di dati ~ informatica triennale (http://www.dsy.it/forum/forumdisplay.php?forumid=211)
-- Social network 2010/2011 (http://www.dsy.it/forum/showthread.php?threadid=41459)

ok questo lo so però le viste vengono usate come fossero tabelle in modo che le operazioni vengano fatte su un sottoinsieme di tutti i possibili dati...

questo mi fa pensare che se io devo visualizzare qualcosa:

1) creo la vista che corrisponderà al risultato della query in quel momento
2) faccio le query che mi servono sui dati nella vista invece che su tutte le tabelle complete

3) quando eseguo un aggiornamento del database (quindi delle tabelle principali -> per esempio aggiungo un amico) le viste non si aggiornano in automatico ma continuano a mostrare i dati di quando le ho create (quindi l'amico appena aggiunto non risulta nella vista) e quindi ogni volta che io chiamo la pagina devo ricreare le viste per aggiornare i dati che queste contengono.

Voglio capire se questa mia visione delle cose è giusta o no.

Allora stai parlando di viste materializzate ed è tutt'altro discorso.

Qualche post prima se ne parlava e ho postato un link ad un altro ragazzo su come gestirle.

Prova a darci un'occhiata

Edit: eri tu

Comunque mi sfugge il senso di tutto ciò: dove sta il vantaggio a materializzare quella vista, se devi sempre ricrearla ad ogni aggiornamento?

Ho dato un'occhiata al progetto: per me intende altro.

Originally posted by progetto

L'utente analista ha funzioni di monitoraggio della comunita. Egli ha accesso a un insieme di statistiche. In particolare, per ogni utente e possibile calcolare un profilo che
riporta il numero di giochi posseduti/provati in relazione al numero medio dei giochi posseduti/provati da tutti gli utenti.

Tutte le funzioni di statistica per l'utente analista sono materializzate e memorizzate in opportune tabelle nella base di dati. E' pertanto necessario realizzare gli opportuni trigger che
mantengano aggiornate tali informazioni a seguito dell'inserimenti di nuovi giochi, dell'acquisizione di nuovi voti e opinioni sui giochi esistenti, e della denizione di nuove relazioni di amicizia
fra utenti.

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

no no allora se vedi l'ultima frase del punto 2 che viene dopo quello che hai riportato, parla del profilo dell'utente.

in sostanza lui vuole che siano usate viste materializzate per le funzioni di statistica e (ho parlato col prof) le informazioni devono proprio essere salvate come tabelle su DB. Quindi lui mi ha detto fai la vista con una select e la salvi su db come fosse una tabella.

poi l'ultima frase dice: "Il profilo di ogni utente comprensivo della lista di amici, dei giochi posseduti e/o votati è realizzato tramite viste"

e qui presumo si intendano viste normali e non materializzate.

la differenza sta solo nel fatto che i dati non vengono fisicamente salvati in una tabella su db ma le viste all'atto pratico vengono usate come fossero tabelle anche se sono virtuali.

per quello penso che per aggiornare una vista l'unico sistema sia ricrearla ogni volta (come viene poi fatto anche nell'articolo che mi hai linkato)

EDIT: è proprio perchè anche a me sfugge il senso di ricreare ogni volta le viste che sto cercando di capire se sto ragionando bene oppure no.

Se te l'ha detto il prof, allora fai come dice lui e copia dal link il procedimento. Mi pare sia fatto bene.

Ad ogni inserimento/aggiornamento (trigger) richiami la cancellazione e creazione della tabella con i dati che ti servono e poi le query del profilo le fai su questa nuova tabella.

In pratica riflettendoci il vantaggio sarebbe che esegui la query 'pesante' solo in caso di aggiornamento di quelle tabelle e non ogni volta che devi visualizzare il profilo.

Il poco senso è che sarà una query con 3 join quindi....

Edit: non pensarle come viste, pensale come tabelle di analisi (report), sennò fai confusione.

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

ok ma a questo punto mi comporto così sia con le viste materializzate che con quelle non materializzate giusto? o meglio più che giusto, ti sembra sensato?

no, le non materializzate una volta che le hai create si aggiornano da sole, non son altro che una scorciatoia: al posto di riscrivere la query con le join ogni volta, fai una select * sulla vista.

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

io ho un dubbio ancora più generale.. a che servono le viste per il profilo?
non si fa prima a mettere sulla pagina i dati dell'utente ed i giochi che possiede/vorrebbe facendo una query su quelle tabelle?
cioè, non saprei proprio che dati mettere nella vista senza creare ridondanza, voi come lo gestite?

Crei la vista che fa le query che ti servono e utilizzi quella nella pagina.

Ovviamente a sto livello le viste servono a poco, però pensa se al posto di avere 'il sito' dove vedere i profili, dovresti controllarli da phpmyadmin, sqlyog o simili.
Dovresti ogni volta riscriverti la query con le join, mentre se ti sei fatto la vista è tutto già pronto.

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

ok proverò ad implementarle così
il fatto di cancellare un gioco che non è stato aggiunto da nessuno invece come lo gestite?

qualcuno mi saprebbe dire dove metterebbe i trigger nel progettino? non ne vedo molta necessità...
e poi nel testo c'è scritto che le amicizie e il profilo degli utenti sono gestiti tramite viste, mentre le statistiche in tabelle (aggiornate con trigger)

questo vuol dire che dobbiamo creare delle tabelle apposite x contenere i dati delle statistiche e le viste x ciò che riguarda l'utente?
Oppure vuol dire che i dati per le statistiche li estrapoliamo direttamente dalle tabelle, mentre per gli utenti passiamo tramite le viste?

Originally posted by pirlo21
[B]
questo vuol dire che dobbiamo creare delle tabelle apposite x contenere i dati delle statistiche e le viste x ciò che riguarda l'utente?

non ne capisco molto il senso...cioè ok per le viste, ma che senso ha creare una tabella con gli stessi dati delle tabelle di partenza? Le statistiche non posso calcolarle con delle query direttamente dalle tabelle di partenza?

Dovrei quindi farmi la tabella:
gioco, numero di utenti che lo possiedono (ad esempio) e tenerla aggiornata con dei trigger ad ogni modifica? Cosa che io farei con una query senza creare un altra tabella

Prova a leggere nei post precedenti che si parlava di viste materializzate (non ricordo se era questo il caso).

Teoricamente avresti delle query molto più leggere da eseguire visto che non servirebbero le join.

Di contro c'è che sta tabella va continuamente aggiornata.

Conviene? Dubito in un progettino del genere, ma se è richiesto...

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Utenti

Scusate ho un dubbio riguardo le categorie di utenza: devo crearle nel database, assegnandogli i relativi permessi, e poi far connettere dall'applicazione gli utenti che appartengono a questa categoria attraverso questo account? Oppure devo creare un account per ogni utente della categoria con i relativi permessi?

Un'ultima cosa...le tabelle che contengono le statistiche vanno inserite nel modello e/r?
essendo entità a sè stanti mi chiedevo se non sia inutile