• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

diferents types of users

 
Greenhorn
Posts: 2
Postgres Database Notepad Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?

 
author & internet detective
Posts: 42103
933
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 68
Netbeans IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Postgres Database Notepad Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
You guys wanna see my fabulous new place? Or do you wanna look at this tiny ad?
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic