.dsy:it. - [Progetto] "Blog"

Pages (33): « 1 2 3 4 [5] 6 7 8 9 » ... Last »
Show 150 posts per page

.dsy:it. (http://www.dsy.it/forum/)
- Basi di dati ~ informatica triennale (http://www.dsy.it/forum/forumdisplay.php?forumid=211)
-- [Progetto] "Blog" (http://www.dsy.it/forum/showthread.php?threadid=28359)

Posted by zonker on 15-02-2007 10:01:

"L’utente quindi non effettua alcun login e l’informazione sull’utente attivo e sul profilo associato viene fornita staticamente all’applicazione, a titolo d’esempio."

Questa frase è relativa al progetto da 3 punti che non prevede che l'applicazione gestisca il login dell'utente.
Visto che ovviamente l'applicazione ha bisogno di sapere qual'è l'utente loggato, non essendoci la parte di login si deve passare staticamente quale sia l'utente collegato all'applicazione in modo che possa funzionare.

Posted by zonker on 15-02-2007 10:06:

- come funziona a grandi linee la creazione della vista per un utente in base al suo profilo attivo? [cut]

La vista è definita "staticamente" sul DBMS, il risultato che è "dinamico" in quando dipende dai dati che estrae la vista.
In pratica si chiede di non usare query SQL complesse nell'applicazione ma di creare delle viste sul DB e poi usare nell'applicazione query che interrooghino tali viste.

- la faccenda dei profili che contengono i dati visibili dell'utente: come si potrebbe (sempre a grandi linee) implementare? [cut]

Ci sono tanti modi, lo puoi far gestire dall'applicazione come hai fatto tu oppure puoi farlo direttamente con una vista nel DB che faccia si che se il campo email (ad esempio) non è pubblico allora restituisca null.

- le statistiche "generali" (quelle tipo quanti contenuti di ciascuna tipologia sono stati inseriti e la media di accessi effettuati) sono memorizzate in una tabella a parte che non e' in relazione con le altre, giusto?

Dipende da come hai disegnato lo schema, ad ogni modo questo direi che è decisamente libero visto che le statistiche non compaiono neppure nello schema concettuale.

- come faccio ad inserire una FOTO in un db? ho letto nei primi post di oggetti di tipo LOB. Cioe' io uploado una foto e posso inserirla nel campo di tipo LOB sotto forma di stream binario? E per aprirla poi come faccio, tratto il contenuto del campo come se fosse un'immagine vera e propria visualizzandola tra i tag img?

Se usi postgres e vuoi gestire le foto nel DB documentati sul tipo OID e sulle funzioni lo_import e lo_export.

Posted by Simeon on 15-02-2007 12:20:

Originally posted by zonker
"L’utente quindi non effettua alcun login e l’informazione sull’utente attivo e sul profilo associato viene fornita staticamente all’applicazione, a titolo d’esempio."

Questa frase è relativa al progetto da 3 punti che non prevede che l'applicazione gestisca il login dell'utente.
Visto che ovviamente l'applicazione ha bisogno di sapere qual'è l'utente loggato, non essendoci la parte di login si deve passare staticamente quale sia l'utente collegato all'applicazione in modo che possa funzionare.

Scusami, ma il punto era un altro. La faccenda dell'utente collegato staticamente penso mi sia chiara, era quella del profilo attivo che mi mandava in confusione. Prima si dice che il profilo attivo di un determinato utente puo' essere cambiato da un utente amministratore, poi si dice che il profilo associato all'utente (quello attivo?) viene stabilito staticamente dall'applicazione. Tutto questo viene detto nella parte relativa al progetto da 3 punti. E' questo che non capisco.

Posted by Simeon on 15-02-2007 12:26:

Originally posted by zonker
La vista è definita "staticamente" sul DBMS, il risultato che è "dinamico" in quando dipende dai dati che estrae la vista.
In pratica si chiede di non usare query SQL complesse nell'applicazione ma di creare delle viste sul DB e poi usare nell'applicazione query che interrooghino tali viste.

Si ma, voglio dire, la vista che creo staticamente nel DBMS dovra' cambiare a seconda degli argomenti che risultano nel mio profilo attivo. Devo crearla tramite funzioni e/o trigger e poi memorizzarla in un campo relativo al profilo? Non mi e' chiaro proprio come/dove possa esser creata una vista ad hoc in relazione al profilo attivo e dove essa debba essere memorizzata (per poi essere richiamata dall'applicazione web nel momento della visualizzazione dei contenuti).

Se usi postgres e vuoi gestire le foto nel DB documentati sul tipo OID e sulle funzioni lo_import e lo_export.

Molto bene.

Grazie anche a te

Posted by zonker on 15-02-2007 13:23:

Per quello che riguarda i profili nel progetto da 5 punti l'utente può creare i propri profili e scegliere quale sia attivo (oltre a poterlo fare l'amministratore), in quello da 3 punti l'utente non può ne loggarsi ne scegliere quale dei sui profili sia quello attivo quindi bisogna passare queste due info in maniera statica.

Posted by zonker on 15-02-2007 13:25:

La vista (schema) mostra tutti gli argomenti (dati) che sono preferiti dall'utente, perchè vuoi cambiare la struttura della vista a seconda delle preferenze dell'utente?
Prova a fare un esempio.

Posted by Simeon on 15-02-2007 13:32:

Originally posted by zonker
Per quello che riguarda i profili nel progetto da 5 punti l'utente può creare i propri profili e scegliere quale sia attivo (oltre a poterlo fare l'amministratore), in quello da 3 punti l'utente non può ne loggarsi ne scegliere quale dei sui profili sia quello attivo quindi bisogna passare queste due info in maniera statica.

Ecco, quindi un utente amministratore, nella versione da 3 punti, NON PUO' cambiare il profilo attivo degli utenti? Sarei portato a pensarla cosi', ma di questa faccenda si parla nella parte generale e non in quella del progetto da 5 punti.

La vista (schema) mostra tutti gli argomenti (dati) che sono preferiti dall'utente, perchè vuoi cambiare la struttura della vista a seconda delle preferenze dell'utente?
Prova a fare un esempio.

Beh non so, se per esempio all'inizio il profilo attivo dell'utente ha come per argomenti sport e politica, allora dovro' fare una vista che estrapoli solo i contenuti che hanno come argomento sport o politica.

Ma se cambio il profilo attivo dell'utente dovro' cambiare di conseguenza anche la vista a seconda degli argomenti no?

Posted by zonker on 15-02-2007 13:54:

L'amministratore può sempre cambiare il profilo attivo sia nei 3 che nei 5 punti, l'utente invece può farlo solo nella versione da 5 punti.
Quindi se sviluppi la versione da 3 punti e vuoi che l'utente scelga quale sia il suo profilo attivo devi farlo staticamente.
Quanto alla vista e al tuo esempio:
PROFILI idprofilo, campo1, camp2, etc
ARGOMENTIPREFERITI idprofilo, idargomento, ordinepreferenza

la vista sarà il join tra le due tabelle e restituirà tante righe quanti sono gli argomenti preferiti per quel profilo.
Come vedi la vista è sempre quella, sono i dati che cambiano.

Posted by Simeon on 15-02-2007 15:36:

Originally posted by zonker
[B]L'amministratore può sempre cambiare il profilo attivo sia nei 3 che nei 5 punti, l'utente invece può farlo solo nella versione da 5 punti.
Quindi se sviluppi la versione da 3 punti e vuoi che l'utente scelga quale sia il suo profilo attivo devi farlo staticamente.

Non mi e' ancora chiarissimo sto punto ma vabbeh, ci pensero'. Perche io pensavo di mettere un flag booleano per indicare se un determinato profilo di un determinato utente era attivo o meno. Pero' questa cosa non ha senso se l'applicazione mi dice staticamente quale sia quello attivo (e quindi non avrei bisogno di controllare flag). Forse non capisco la storia dello "staticamente".

Comunque ci lavorero' su.

Per la vista ok, non mi venivano proprio in mente i join.

Posted by zonker on 15-02-2007 15:45:

Per il profilo è esattamente come hai capito ed è giusto il flag booleano.
Il problema è solo relativo al fatto che l'utente in questo modo non può specificare quale sia il suo profilo attivo, se non lo passi staticamente devi entrare come amministratore, cambiare il profilo attivo dell'utente e poi rientrare come utente.
Che peraltro credo sia accettata come soluzione.

Posted by khelidan on 15-02-2007 17:21:

Originally posted by zonker

PROFILI idprofilo, campo1, camp2, etc
ARGOMENTIPREFERITI idprofilo, idargomento, ordinepreferenza

la vista sarà il join tra le due tabelle e restituirà tante righe quanti sono gli argomenti preferiti per quel profilo.
Come vedi la vista è sempre quella, sono i dati che cambiano.

In questo caso avrai ridondanza,per ogni argomento preferito avrai i campi di profilo ripetuti,stavo pensando anche io ad una alternativa,non si puo fare un count sul totale degli argomenti e fare una vista con i dati di profilo ed un campo per ogni argomento?E tecnicamente fattibile?

__________________
Khelidan

Posted by zonker on 15-02-2007 18:07:

No, per entrambe.
PROFILI e ARGOMENTIPREFERITI sono due tabelle, proprio per evitare la ridondanza, ovviamente ho dato per scontata l'esistenza di una tabella ARGOMENTI in cui ci sono i campi relativi agli argomenti.
Quindi i PROFILI ci saranno i campi dei profili ripetuti una sola volta e con idprofilo in chiaro, in ARGOMENTI ci saranno i campio degli argomenti ripetuti una sola volta con idargomento in chiaro e ARGOMENTIPREFERITI sarà appunto la tabella che mette in relazione molti a molti i profili con gli argomenti.
Quanto alla tua soluzione è "errata" per definizione: lo schema non deve variare in funzione dei dati mentre tu proponi di variare la definizione della vista (e quindi lo schema) ogni volta che inserisci o rimuovi un argomento, a meno che io non abbia capito quello che intendevi.

Posted by khelidan on 15-02-2007 18:14:

Originally posted by zonker
No, per entrambe.
PROFILI e ARGOMENTIPREFERITI sono due tabelle, proprio per evitare la ridondanza, ovviamente ho dato per scontata l'esistenza di una tabella ARGOMENTI in cui ci sono i campi relativi agli argomenti.
Quindi i PROFILI ci saranno i campi dei profili ripetuti una sola volta e con idprofilo in chiaro, in ARGOMENTI ci saranno i campio degli argomenti ripetuti una sola volta con idargomento in chiaro e ARGOMENTIPREFERITI sarà appunto la tabella che mette in relazione molti a molti i profili con gli argomenti.
Quanto alla tua soluzione è "errata" per definizione: lo schema non deve variare in funzione dei dati mentre tu proponi di variare la definizione della vista (e quindi lo schema) ogni volta che inserisci o rimuovi un argomento, a meno che io non abbia capito quello che intendevi.

Così è esattamente come ho fatto anche io,ma il testo non dice anche che bisogna avere una vista con dati del profilo attivo,dell'utente ed i suoi argomenti preferiti?In pratica bisogna unire in una vista le tre tabelle con solo i profili attivi?Per ora ho implementato facendo il join ma nei requisiti c'è scritto di fare tramite vista!

Per la vista che avevo proposto hai ragione è concettualmente errata!

__________________
Khelidan

Posted by khelidan on 15-02-2007 18:17:

la vista in pratica si comporrebbe dei campi di utente,i campi della tabella profilo e quella argomentipreferiti,in questo caso non avremmo una riga per ogni argomenti preferito nella vista?I dati nelle prime due tabella saranno uguali a ogni riga,cambia solo l'argomento preferito!

__________________
Khelidan

Posted by zonker on 15-02-2007 18:19:

La vista sarà appunto il join, anzichè fare dall'applicazione
Select a, b, c, d from t1 join t2 join t3 (mi si passi la "volgarizzazione" della sintassi SQL), questa stessa query genera la vista quindi create view v1 as select a, b, c etc, etc e poi l'applicazione farà una select a, b, c from v1 where etc etc

All times are GMT. The time now is 19:03.

Pages (33): « 1 2 3 4 [5] 6 7 8 9 » ... Last »
Show all 481 posts from this thread on one page