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 sayin
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
to be able to pull the correct one
based on date
bastien
> To: php-db@lists.php.net
> From: [EMAIL PROTECTED]
> Date: Wed, 24 Oct 2007 09:06:29 -0400
> Subject: [PHP-DB] Question about database design
>
> I sent this to the MySQL list but didn't receive any
>
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
addresses to be able
to pull the correct one based on date
bastien> To: php-db@lists.php.net> From: [EMAIL PROTECTED]> Date: Wed, 24 Oct
2007 09:06:29 -0400> Subject: [PHP-DB] Question about database design> >
I sent this to the MySQL list but didn't receive any > resp
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 actua
I sent this to the MySQL list but didn't receive any
response, My apologies if you have already received this.
Hi Everyone,
So having learned my lesson with the last application, I am trying to
plan out the addition of a feature to my database application.
Basically, some of my custom
