Jeanne Boyarsky wrote:It dpeends on what you are doing with the user info. For logging on, one table makes sense. For attributes (amount spent maybe), separate tables makes sense. For the user id/role mappings, one table is good as you suggest.
Thank you, I used one table because it is a very simple logging
Philip Grove wrote:I would suggest a model with three tables. One for users and ID, one for potential roles and ID, and a relation table that has a tie between user IDs and role IDs. I have used this model myself and while it seem more complicated, I have found it simple to use. It does require some more complicated statements but nothing a JOIN can't do for you.
The model you suggest sounds fine for a more complex logging, i think that using a table to connect user IDs and role IDs means that its a many-to-many relation, in this simple example that I'm making, each user can have one and only one role, and each user log in in a different URL, that's makes it even simpler I guess. I'll try your model when i have more roles and users, thank you
