[thelist] Where to Store Username and Password in SQL Tables

[Boris Mann]

I would think that the main pitfall is if you want to add a third type
of user. Maybe each manufacturer wants to designate an "editor" contact
that  can access stuff in their row, but not delete it or change
critical info (like the main contact email). Nopw you're stuck having
to add another table, create more SQL queries to access it, etc.

I would think that a "users" table that has a "role_id" field, as well
as an associated "roles" table would be the way to go. And, even if you
initially have two types/roles of users, it's still only two tables.

Your logic could be a case statement on the value of the "role_id"
field -- you can add as many different roles as you want, each with
their own case statement for what their "permissions" are.

Even better, make a function or class method called
userHasPermission(user_id) which just returns true or false, and you
can write it any way you want on the inside.

--
Boris Mann
http://www.bmannconsulting.com

On Monday, January 27, 2003, at 03:45 PM, RUST Randal wrote:

> I have two types of users in my application: Admins and Widget
> Manufacturers.  Admins have access to everything, Manufactuers can only
> access their particular row in the Manufacturers table.
>
> It seems really easy to just store the Username and Password in each
> table accordingly.  Like this...
>

<snip>separate table for each user type</snip>

> But are there any pitfalls to this approach?  Should I create a Users
> table?
>
> ----------
> Randal Rust
> Covansys Corp.
> Columbus, OH