[thelist] Where to Store Username and Password in SQL Tables
RUST Randal
RRust at COVANSYS.com
Tue Jan 28 08:36:04 CST 2003
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
More information about the thelist
mailing list