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

[RUST Randal]

Rudy said:

> how do you collect this?  paper form?  fax?  phone?  web form?

Web.

> who submits it?  you?  superuser?  sysadmin?  any joe user?

Any Joe User.

> my suggestion:  you want one web form to "add a user" and
> this function should make no distinction between what kind of
> a user it is, so this function can be used by everybody

That's what I'm working on now.

> then you want a different function that associates a
> particular existing user to a particular manufacturer, and
> this separate function should be restricted to those with the
> appropriate permission

Right.  And that's really my question.  How do I create this
association?  I could use email address, I think.

> i would design it so that if fred is already a user for the
> xyz company, fred has the ability to relate any other
> existing user to xyz company

Yes.  Fred will need to add some workers to a table, and associate them
with his company with the Manufacturer_ID.

> as for portability, do everything with your own data tables,
> not some "permissions" feature of the database vendor

Yes. That's what I'm trying to aim for. This way I can move between
databases more easily.

> in terms of the database design, all you need is a foreign
> key in the user table that points to the manufacturer table
> (many-to-one design, many users to one manufacturer)

So I can use the email address as the foreign key, right?  If I'm not
grasping this, Rudy, then let me know.  I'm trying to gather a lot of
knowledge here in a short time, and can go look at some more reference
material if I need to.

> unless, of course, you want a given user to be able to
> control multiple manufacturers, in which case you should go
> for the separate many-to-many relationship table

This is a possibility, but I think that I would like to avoid it for
now.

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