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

[RUST Randal]

Rudy said:

> > Randal Rust said:
> > Should I create a Users table?

> ayup

> and store a value in a column called Admin to differentiate
> between the two types of user

OK, so I need a Users table. All the arguments put forth make sense. Now
I have another question, regarding adding a new user via the Web
interface. Here are the columns in my two tables...

USER TABLE COLUMNS
User ID (PK)
F_Name
L_Name
Username
Password
Type

MANUFACTURER TABLE COLUMNS
Man_ID (PK)
Company_Name
Phone
Fax
Email

Now, when a Manufacturer creates a new account, I'm not sure how to
associate them with both tables, because I would need to add to both
tables during sign up.  I have a couple of ideas though.

1) When the Manufacturer signs up, I just collect the data that goes
into the User table.  Then when they log in, I will know that they are
of Type "Manufacturer" and I can direct them to complete the information
needed.  This is the information that goes into the Manufacturer Table.
If I did it this way, I could associate the Manufacturer row with the
User row by adding the User ID as a Foreign Key to the Manufacturer
table.

2) When the Manufacturer signs up, collect all of the necessary data.
Put the data in the appropriate table.  This is how the client wants it
done.  The problem is that I'm unsure of what value I should use as the
Primary Key to associate the two tables.  Would email work here?  It
would have to be a PK in the User Table if that's the case.

So I've come up with a couple of options.  I read up on MySQL Grant
Tables last night, but I need to create *my own thing,* because I don't
want to be tied into a particular database.  If I can figure out which
direction that I need to go, I can probably write all of this. I'm just
unsure of which path to take at this point.

----------
Randal Rust
Covansys Corp.
Columbus, OH