users e members, id e member_id
Ogni buon ingegnere del software avrebbe detto: creiamo una tabella utenti e una flag deciderà se quell'utente è membro oppure no. Le informazioni manteniamole nella stessa tabella per entrambe le categorie. Sarebbe stata una buona idea, in fondo. Purtroppo non è l'idea che è passata in mente quando la struttura del sito è stata progettata.
Users è la tabella effettiva di utenti e membri. Il campo permission decide a quale categoria ogni utente fa parte.
users.permission:
0 = Admin
1 = Founder Member
2 = Member
9 = Normal User
La tabella members si affianca a quella users in certe situazioni. La tabella members ad esempio contiene le informazioni del profilo, esperienze lavorative, medaglie, ecc. Ci sono due ridondanze nella tabella members. Qualcuno l'avrà notato, ma ad esempio se cliccate sul profilo di "Piero Tofy", verrete reinviati alla pagina dell'utente conosciuto nel forum come "pierotofy". Da quando il sistema di ammissione membri è diventato semi-automatico, questa ridondanza virtualmente non c'è più (users.user == members.nickname), ma c'è ancora a livello di programmazione. Oltre a questo, users.mail == members.mail.
Mmm... e il campo userID per la join fra le due tabelle dove sta? Non c'è. La join tra le due tabelle viene fatta tramite il campo mail (oddio!). Ad oggi un campo userID per linkare le due tabelle è ancora da creare.
Questa ambiguità fra le due tabelle non è stata molto utile. Al contrario noterete che quando bisogna far riferimento ad un utente (ad esempio, chi ha creato il progetto X? Chi ha caricato il programma Z? Chi ha postato il messaggio Y nel forum?) c'è un brutto mix. Nello specifico ci sono tre vie per referenziare il proprietario di un oggetto (progetto, programma, articolo, ecc.).
Numero 1 (più vecchio, presente nel sito e assolutamente da evitare!): usare members.nickname. Esempi sono la tabella articoli (tutorials) e dei programmi (programs). Nei campi tutorials.members_nickname e programs.programmer viene indicato a lettere (ad esempio "Piero Tofy") il proprietario di un articolo.
Numero 2 (meno vecchio, presente nel sito e da evitare!): usare members.id. Esempio sono i progetti (projects) e advguides, advchapters (le guide del sito come quella al Visual Basic .NET di Totem). In questo caso members.id è stato utilizzato.
Numero 3 (recente, da usare per il futuro!): usare users.id. Questo è un campo ID univoco che comprende sia members che normal users, ed è quello che è da usare (messaggi privati, forum, muro e tante altre parti utilizzano questo sistema).
Come si fa quindi a capire cosa sta succedendo? Come faccio a referenziare un utente e sapere come fare le join senza rompere la compatibilità con vecchio codice? Per far fronte a questo, tutte le nuovi parti di codice devono utilizzare l'oggetto $currentUser, che viene istanziato ad ogni richiesta e contiene metodi e membri utili per far riferimento ad un utente. Per maggiori informazioni leggere /etc/lib/libcurrentuser.php.
|
