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

Originally posted by zonker
Certo il diritto di cancellazione va gestito esattamente come quello di modifica.
Qualcuno ha il documento sulle modalità di consegna? Il link sul sito non funziona più...

Grazie mille, il link che non va è sul sito del turno 2

secondo voi l'admin è da considerare un utente come gli altri oltre ad avere poteri di amministrazione,nel senso partecipa con un profilo ecc....?

__________________
Khelidan

E' una scelta implementativa, di fatto dalle specifiche non è richiesto che abbiano profili preferenze etc. però è richiesto che abbiano permessi illimitati sui contenuti quindi potrebbe essere più comodo gestirli come utenti e nella vista/query/funzione che estrapola i premessi di modifica gestire che se l'utente è di tipo admin allora abbia sempre il premesso.
Ultima nota GLI utenti amministratori possono essere più d'uno.

io li gestisco come utenti,poi quando vado a fare una query come dici te controllo un attributo tipo per vedere se sono admin,almeno mi sto orientando così!

__________________
Khelidan

si anche io.

Originally posted by zonker
Infatti non lo fai con i trigger.
Ti crei una funzione che incremente il numero di accessi e poi la usi in una vista.
Ad esempio crei una funzione incrementaaccesso(idcontenuto) e poi quando accedi ai contenuti lo fai con una vista tipo SELECT IDCONTENUTO, incrementeaccesso(IDCONTENUTO), DIMENSIONE, TIPO FROM CONTENUTI

__________________
Khelidan

crei una funzione come fai per i trigger, ma che restituisce ad esempio un intero.
Ad esempio:
CREATE FUNCTION incrementaAccessi(v_contenuto INT) RETURNS INT AS $incrementeAccessi$
Dentro questa funzione fai una update della tabella andando ad incrementare in numero degli accessi effettuati.
Ora se fai:
SELECT ID, TITOLO, incrementaAccessi(ID) FROM CONTENUTI WHERE ID = 15;
quello che avverrà sarà che ti verranno restituiti ID, TITOLO e il risultato dell'esecuzione della funzione incrementaAccessi sul contenuto con id 15.
Così hai i dati che ti servono e hai incrementato il numero degli accessi a quel contenuto.
E' più chiaro ora?
Quanto al fatto di farlo direttamente con una select o all'interno di una vista è assolutamente indifferente, ma mi sembra che nelle specifiche ci sia indicato che gli utenti accedono ai contenuti attraverso viste.

Chiarissimo,mi hai tolto un bel dubbio! grazie mille!

__________________
Khelidan

figurati, e' un piacere.

Mi sto avvicinando ora al progetto e devo ammettere di avere le idee un tantinello confuse. E' piu' semplice di quello di algoritmi (almeno credo), ma il C mi e' decisamente piu' familiare della triade sql-apache-php.

Comunque: mi sapreste spiegare un attimo cosa significa questo? "Un profilo
stabilisce quali dati dell’utente siano visibili ad altri utenti e quali siano gli argomenti
preferiti dell’utente, in ordine di importanza."

Dunque la faccenda degli argomenti mi pare ben chiara ma non bene quella su "quali dati dell'utente siano visibili ad altri utenti". Si riferisce forse, che so per esempio. ad un profilo particolare che magari nasconda l'email come visibilita'?

E poi, se ad un utente generico corrispondono 1 o piu' profili, ad un profilo corrisponde un solo utente o piu' di uno? Visto che definiamo un certo profilo per un determinato utente, mi verrebbe da dire che ad un profilo corrisponde un utente (quindi 1:1).

Lo so che sono domande stupide ma purtroppo mi riesce difficile avvicinarmi a sto tipo di progetto.

E inoltre ad esempio: noi abbiamo sia utenti GENERICI che utenti AMMINISTRATORI.

Mettiamo che nel DB io li raggruppi in un'unica entita' superclasse chiamata "utente" con un bell'attributo che me li distingua.

In questo caso, se un'istanza dell'"utente generico" fosse in relazione con 1-N profili, un'istanza della mia nuova superclasse "utente" sarebbe in relazione con 0-N profili giusto? Perche un utente amministratore non ha profili, dico bene?

Direi basta per stasera

Meno male che avevo detto basta...

E' che sto facendo lo schema concettuale e ho scoperto di avere diversi dubbi soprattutto sulle cardinalita' minime.

Per esempio, prendiamo la relazione profilo - R - argomento

Un argomento dovrebbe essere associato a 0,n profili, e qui direi ok.

Ma un profilo e' associato a 1,n argomenti o a 0,n argomenti? In quest'ultimo caso un profilo senza argomenti non visualizzerebbe contenuti oppure li visualizzerebbe tutti?

E ancora, possono esistere utenti senza profili?

Boh dubbi dubbi dubbi, non capisco se siano scelte implementative o se la soluzione giusta sia necessariamente una sola.

secondo me sono scelte implementative, le specifiche, d'altra parte, sono abbastanza generiche e questo tipo di decisione sono laciate a chi sviluppa il progetto. Anch'io avevo chiesto qualcosa al riguardo alla prof. castano e mi ha detto che l'importante è spiegare le scelte fatte nella documentazione.

Originally posted by Simeon
php.

Comunque: mi sapreste spiegare un attimo cosa significa questo? "Un profilo
stabilisce quali dati dell’utente siano visibili ad altri utenti e quali siano gli argomenti
preferiti dell’utente, in ordine di importanza."

Dunque la faccenda degli argomenti mi pare ben chiara ma non bene quella su "quali dati dell'utente siano visibili ad altri utenti". Si riferisce forse, che so per

esempio. ad un profilo particolare che magari nasconda l'email come visibilita'?

E poi, se ad un utente generico corrispondono 1 o piu' profili, ad un profilo corrisponde un solo utente o piu' di uno? Visto che definiamo un certo profilo per un determinato utente, mi verrebbe da dire che ad un profilo corrisponde un utente (quindi 1:1).

__________________
Khelidan