It's not a secret anymore!*
The moose likes JDBC and the fly likes diferents types of users Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "diferents types of users" Watch "diferents types of users" New topic
Author

diferents types of users

Pablo Mendoza
Greenhorn

Joined: Nov 16, 2011
Posts: 2

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

Joined: May 26, 2003
Posts: 30789
    
157

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Philip Grove
Ranch Hand

Joined: Aug 18, 2009
Posts: 68

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

Joined: Nov 16, 2011
Posts: 2

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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: diferents types of users