Quote:
Originally Posted by ronf57
my tables ALL relate to userID and they are the primary key in each.
|
in that case, they should really not be separate tables, but rather, just one table
for example, let's consider your users table
userID is the primary key, which means that it must be unique
so you can have only one Todd, only one Fred, only one Biff, and so on
in your useraddress table, if userID is the primary key, this again means that you can have only one Todd, only one Fred, only one Biff, and so on
in other words, you can have only one address per user
therefore you should combine the users and useraddress tables
on the other hand, if you ~want~ a user to have more than one address, you ~do~ need separate tables, and the userID ~cannot~ be the primary key of the useraddress table, simply because of the fact that you want there to be more than one row for any given userID
make sense?
it is in this latter case (where there will be multiple rows in the useraddress table for each userID), that you will want userID to be a foreign key, not the primary key
this leaves open the question of what should be the primary key for the useraddress table, and without going into a lot of detail, an auto_increment here is probably your best bet
p.s. here's a link where you can order my book --
https://sitepoint.com/bookstore/go/150/9cdb0e6
