• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

diferents types of users

 
Pablo Mendoza
Greenhorn
Posts: 2
Java Notepad Postgres Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I just started using DBs and i was wondering how should i handle different kind of users, for example, within an on-line store database.

I have costumers ans administrators, should I have a "kind of user" attribute in the users table, a different table for each kind of user or a new table with roles/userId attributes?

 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34863
369
Eclipse IDE Java VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Philip Grove
Ranch Hand
Posts: 68
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 two table model has the weakness that given a username or ID you don't know where to find the user. Furthermore you run the risk of having two users with the same ID, and as comparing ints is significantly faster than comparing strings you want a unique ID for every user.
 
Pablo Mendoza
Greenhorn
Posts: 2
Java Notepad Postgres Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic