[thelist] Where to Store Username and Password in SQL Tables
RUST Randal
RRust at COVANSYS.com
Tue Jan 28 10:04:00 CST 2003
Rudy said:
> it's difficult without pictures ;o)
> a data model diagram would help you understand the relationship
Following your words, I drew a picture. I understand it perfectly.
> p.s. did this help?
Yes, it did. That was an excellent explanation. But one thing is still
tripping me up. My tables now look like this:
USER
User_ID (PK)
Man_ID (FK)
Username
Password
Type
MANUFACTURERS
Man_ID (PK)
Address
and so on...
How do I go about adding all of this at the same time? No PK exists
until I execute the query to add the data to the Manufacturers table.
What I'm not grasping is how I pull the PK from the Manufacturer's table
when I create the User.
Does this make sense?
if(data is ok && no duplicate information){
$sql=insert into manufacturers (values);
if($sql){
$last=last_insert_id(manufacturers);
$sql="select * from manufacturers $last";
$foreignKey=$last;
$sql="insert into users(values); }
}
Hopefully I'm not losing you:)
----------
Randal Rust
Covansys Corp.
Columbus, OH
> -----Original Message-----
> From: rudy [mailto:r937 at interlog.com]
> Sent: Tuesday, January 28, 2003 10:39 AM
> To: thelist at lists.evolt.org
> Subject: Re: [thelist] Where to Store Username and Password
> in SQL Tables
>
>
> > So I can use the email address as the foreign key, right?
> > If I'm not grasping this, Rudy, then let me know.
>
>
> maybe i can describe it in words
>
> you have two tables, user and manufacturer
>
> you want a relationship where multiple users can administer a
> manufacturer, but any individual user can administer only one
> manufacturer
>
> that's a many-to-one relationship, with your user table on
> the "many" side, and your manufacturer on the "one" side
>
> rule: the foreign key resides in the "many" table
>
> some people use the term "parent-child" to describe a
> one-to-many relationship, and say "the child always points to
> the parent"
>
> however, others find this terminology confusing, perhaps
> because you have to explain why a child doesn't have two
> parents and why both are in the same table
>
> the one-to-many relationship is also called "master-detail"
>
> my own mnemonic, the way i remember primary and foreign keys
> in relationships, is good old sql, not least because it's so
> nice and compact and so takes up less room in my brain
>
> the sql syntax that declares a foreign key is
>
> foreign key ( foo ) references bar
>
> foo is the column name of the foreign key, and bar is the
> table name of the table that has the primary key that the
> foreign key foo references
>
> since primary keys are unique, this means that bar is the "one" table
>
> mnemonic: unique = one
>
> this, in turn, by process of elimination, there being only
> one table left to choose from, means that foo resides in the
> "many" table
>
> easy ;o)
>
> so in your database, randal, user is the "many" table and
> manufacturer is the "one" table
>
> thus, user contains a column that is a foreign key that
> references the primary key of the manufacturer table...
>
> the primary key of the manufacturer table is man_ID
>
> drum roll, please
>
> so the user table foreign key column should be: man_ID
>
> alternatively user_man_ID
>
>
> rudy
>
> p.s. did this help? if so, please let me know, maybe i
> should write these long explanations up somewhere
>
> you know, it's hard to write stuff using small words
>
> i saw a web page yesterday that totally floored me --
>
> Theory of Relativity in words of four letters or less
> http://www.muppetlabs.com/~breadbox/txt/al.html
>
>
> --
> * * Please support the community that supports you. * *
http://evolt.org/help_support_evolt/
For unsubscribe and other options, including the Tip Harvester
and archives of thelist go to: http://lists.evolt.org
Workers of the Web, evolt !
More information about the thelist
mailing list