Newsgroup: it.comp.www.php
Titolo: perchè tante tabelle?

con l'intenzione di creare uno script di login per gestire i membri, ho
iniziato a cercarne in internet qualcuno. ne ho trovati diversi con
buone funzionalità (ad es la gestione degli admin, utenti bannati e
altro) e li hos scaricati.
dopo averne installato uno, sono andato a vedere nel database come era
organizzata l'appartenenza ai gruppi e altri dettagli.
stupefatto, vedo che sono state create 3 tabelle: una per gli utenti
(users), una per gli utenti bannati(users_banned), una per gli
amministratori (admin)
in uno stato di confusione non indifferente, mi appresto ad instalare
il secondo script e... ci sono 3 tabelle anche lì! installo il
terzo... 3 tabelle, il quarto... 4 tabelle (una anche per i
superusers)...
io, che avevo già fatto un abbozzo del mio script per il login, avevo
previsto una sola tabella (users) nella quale c'erano diversi campi (ad
es is_banned, group...) nel quale venivano scritti i valori
corrispondenti all'utente.
probabilmente c'è qualcosa (che non conosco! :-( ) che rende più
sicuro o più pratico l'utilizo di diverse tabelle per identificare un
certo utente...
voi che ne dite? è davvero più sicuro o è solamente una questione di
gestione più immediata?
ciao gg

Puoi fare una tabella con un campo che identifica il tipo di utente.
Ad esempio il campo userType=1 identifica gli Admin.
Puoi anche fare più campi con funzione di flag che identificano vari
privilegi cumulabili.
userAdmin=0, userMod=1, significa che l'utente non è Admin ma è
moderatore.
L'uso di più tabelle è una scelta non obbligata.
Capirai però che nel secondo esempio che ti ho fatto, se un giorno
vorrai introdurrela tipologia di utente userSuperMod, dovrai fare un
alter table.
Pensa a come deve essere la tua gestione utenti e a come potrebbe
svilupparsi in futuro.
GG ha scritto:


Ciao ,non sono un esperto di DB Design ma In generale penso che devi
considerare le query che farai sul DB.
Se l'unica funzione che utilizzerai sarà quella di login per
autenticare gli utenti e privare loro dell'accesso a POCHE
funzioni/aree riservate a POCHE altre tipologie di utenti e non devi
considerare problemi di scalabilità per un gran numero di utenti...
allora la soluzione con unica tabella e campi addizionali del tipo
isAdmin,isBanned ecc... è preferibile.
Dall'altro lato la soluzione con più tabelle che senza dubbio ti
permette scalabilità in futuro grazie al fatto che riduci il numero di
righe per ogni tabella ,  è  preferibile nel caso in cui
il tuo sistema tratta tipologie di utenti che hanno campi diversi che
sono in relazione con altre tabelle del DB per svolgere precise
funzioni (query) diverse da tipologia a tipologia di utente.
Naturalmente in questa soluzione ogni operazione come quella di Login
sarà fatta contestualmente alla tipologia di utente scelta.
Ad esempio in un sito web, nell'area admin/ la query per la verifica
Login sarà effettuata sulla tabella "amministratori" e non sulle altre
tabelle come "utenti" o "utentiBanned".
Ci saranno quindi diverse aree per il login contestuali alla tipologia
di utente che deve accedere.
Una soluzione di mezzo , che da una parte però colpisce la
scalabilità (anche se parzialmente) consiste nell'utilizzo oltre che
di tutte le tabelle per diverse tipologie di utenti con campi specifici
,di  una tabella singola  USERS(user,password,typeUser)
che mantiene tutte le informazioni principali per la verifica login
indipendente dal tipo di utente , ma che permette poi utilizzando il
campo 'typeUser' di individuare la tipologia di utente.Successivamente
solo dopo aver verificato user e password,  incrociando i dati  con le
relative tabelle (amministratori,superuser,utenti,utentiBanned) si
possono
ottenere i campi addizionali specifici.
Spero di averti dato un pò di informazione che ti permetterà di poter
scegliere da solo in base alle tue esigenza lo schema del DB
appropriato.
;)
Ciao


svilupparsi in futuro.
dovrebbre essere piuttosto lineare.. nel senso che non credo che
aggiungerò altri campi.
quindi la sicurezza non c'entra niente... lol avevo subito pensato a
strani controlli incrociati e valori misteriosi e invece...
grazie ciao

 amministratori (admin)
Un'organizzazione del genere la trovo abbastanza strana.
Trovo normale fare diverse tabella, ma non cosi`.
Per esempio io userei una tabella "user", una "group" e una "user_group"
che li mette in relazione. Eventualmente puoi (tenendo il DB normalizzato)
fare una tabella "privilege" che metterai in relazione con la "group"
tramite "group_privilege", oppure puoi denormalizzare e definire i
privilegi nelle colonne della tabella group, magari codificati (come ai
vecchi tempi tramite costanti in OR tra loro per risparmiare spazio :)
In questo modo puoi associare ogni utente a uno o piu` gruppi, e assegnare
privilegi diversi ad ogni gruppo. Puoi anche cambiare i privilegi di un
gruppo con una sola "update" o spostare un utente da un gruppo a un altro,
sempre con una update.
Poi la struttura dipende dal progetto che devi realizzare.
Bye.

 vecchi tempi tramite costanti in OR tra loro per risparmiare spazio :)
Quindi, se ho capito il procedimento --sai, sono ancora un pivello...
:(
* Inserisco in "groups" tutti i gruppi che mi servono (users, admin,
superusers, ecc)
* Alla registrazione dell'utente inserisco i suoi dati nella tabella
"users" e il suo   username in "users_group".
* In corrispondenza dell'username nella tabella "users_group"
dovrebbero esserci i gruppi di appartenenza, ma non ho capito come...
                              //** COME SONO ORGANIZZATI? **//
* Per controllare se un'utente appartiene ad un gruppo basta verificare
se il suo username è associato al ruolo giusto nella tabella
"users_group"
* Per cancellare un utente elimino i dati in corrispondenza del suo
username nelle tabelle "users" e "users_group"
* Per aggiungere un utente ad un gruppo devo modificare la tabella
"users_group"...
                            //** IN CHE MODO? **//
* Per aggiungere o togliere un ruolo aggiungo/elimino i dati nella
tabella "groups"
Puoi dirmi se il procedimento è coretto e correggermi dove sbaglio?
Grazie GG

 tabella "groups"
Esatto.
 
Bye.

 l'id che viene generato e lo metti in user_group con
Per prendere l'id generato faccio una select
          SLEECT id FROM users WHERE username = $_POST['username']  //
$_POST['username'] corrisponde all'username fornito dall'utente in fase
di registrazione
o c'è un altro modo?
E poi è possibile consentire ad un utente di appartenere a più di un
gruppo? Se sì (come credo), e' necessario cambiare molto lo schema
delle tabelle e i campi?
Grazie
Alessandro Pellizzari ha scritto:


 tabelle e i campi?
Non devi modificare niente. Ti faccio un esempio senza gli id,
direttamente usando username e groupname:
insert into group (groupname) values ('Admin');
insert into group (groupname) values ('Superdmin');
insert into group (groupname) values ('Blogger');
insert into user (username, password) values ('pippo','pluto');
insert into user_group (username, groupname) values ('pippo','Admin');
insert into user_group (username, groupname) values ('pippo','Blogger');
Quando vuoi sapere a che gruppi appartiene, scrivi
select * from user_group where username='pippo';
che ti torna una riga per ogni gruppo.
Se vuoi sapere se un utente appartiene a un gruppo:
select * from user_group where username='pippo' and group='Superadmin';
che ti torna 0 righe se non appartiene, 1 riga se appartiene e piu` di una
se hai il DB corrotto (per l'indice univoco che ti dicevo).
Bye.

ok, ora è davvero tuto hiaro, grazie!
non avevo pensato alla possibilità di utilizzare per lo stesso utente
più righe della tabella facendo si che venisse associato a più
gruppi...
a presto gg
Alessandro Pellizzari ha scritto:
