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

[RUST Randal]

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 !