Hi Jason,
There are a couple ways you could do this. Yes, this would make it a
relational database.
If you go with a second table, you'll want to be sure to include the UID
from the main address table in the SnowBirds table so that they are
linked. The UID in the second table would
I would approach this by having a main people table (with a unique id of
course) and then create a second addresses table which uses the people Id key
as the foreign key to this table...then you can have multiple (more than two)
addresses for those users, you could add a season in the
Hi Tim,
Right now the customer I have has about 1,000 records which I know
isn't alot for MySQL to handle, but if people like the application we
could end up with 15 to 20 all having around 1,000 or more records
which would add up more on the database. Although right now I plan to
have a
I think I understand what you are saying here... On the main table
just list the persons name and then on a second table use a 1 to many
relationship on a foreign key to link all the addresses into the
name? Or did I miss the mark? :)
On Oct 24, 2007, at 9:30 AM, Bastien Koert wrote:
I
A second address table is definitely the way to go (the '*' signifies the
primary key):
People Table
*user_id
first_name
last_name
etc
Address Table (compound primary key)
=
*user_id (fk to People Table)
*address_id
*obs_no (you can skip this if you don't want to keep an
Nope, you got it
Bastien
CC: php-db@lists.php.net From: [EMAIL
PROTECTED] Subject: Re: [PHP-DB] Question about database design Date: Wed, 24
Oct 2007 15:18:05 -0400 To: [EMAIL PROTECTED] I think I understand what you
are saying here... On the main table just
