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 customers go south for the winter ("Snow
Birds") what I would like to do is have away of storing both their
addresses in the database, and have it so that the people
administering the list can choose between wether they are up north or
down south without having to erase the old address.

For that I was thinking creating a second table "SnowBirds" and list
their southern addresses in there and then when the list admin clicks
on the edit button for their name, it would also be able to pull up a
list of the the addresses stored and associated with that person.

I'm also considering adding a date range for the addresses so that if
they know they'll be south from November to March it will check the
date and switch between the record accordingly BEFORE exporting to
excel.

Now... I haven't really asked a question yet but gave some background
into what I want to do. Sooooo... Here's the question, does anyone
have any advice on the best way to do it? Am I right in thinking that
a second table is required? Would it be called a Relational database?
Or have I missed the terminology?

Any help would be greatly appreciated!

Thanks for looking!

ohhh... and in case it makes a difference it's MySQL 5.* and I'll be
writing the stuff to access that database with php 5.

--

Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruim@raoset.com

Jason Pruim a écrit :
> 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 customers go south for the winter ("Snow Birds")
> what I would like to do is have away of storing both their addresses in
> the database, and have it so that the people administering the list can
> choose between wether they are up north or down south without having to
> erase the old address.
>
> For that I was thinking creating a second table "SnowBirds" and list
> their southern addresses in there and then when the list admin clicks on
> the edit button for their name, it would also be able to pull up a list
> of the the addresses stored and associated with that person.
>
> I'm also considering adding a date range for the addresses so that if
> they know they'll be south from November to March it will check the date
> and switch between the record accordingly BEFORE exporting to excel.
>
> Now... I haven't really asked a question yet but gave some background
> into what I want to do. Sooooo... Here's the question, does anyone have
> any advice on the best way to do it? Am I right in thinking that a
> second table is required? Would it be called a Relational database? Or
> have I missed the terminology?
>
> Any help would be greatly appreciated!
>
> Thanks for looking!
>
> ohhh... and in case it makes a difference it's MySQL 5.* and I'll be
> writing the stuff to access that database with php 5.
>
> --
>
> Jason Pruim
> Raoset Inc.
> Technology Manager
> MQC Specialist
> 3251 132nd ave
> Holland, MI, 49424
> www.raoset.com
> japruim@raoset.com
>
>
>
Hi,
Well that's a way to add a second address to your current application.
It may or may not be the best way tough.

I think, the cleanest way of doing it would be to modify your current
existing address table to add a field that say the type of address it
is. Something along the line Type: "Primary, Secondary, Temporary" and
possibly along that date field to keep the information about the date if
needed.

This however changes your join type, meaning that stuff that actually
joins with the address table could now return more than 1 row per user
so you'll have to adjust more code than your initial plan.

So depending of the current size of the application and the
maintenance/upgrade possiblity, you may want to consider other
solutions. This one for example has the advantage to allow you to store
more than 2 types of address along a user and keep all the address in
the same table instead of having 2 tables that store more or less the
same kind of information

Regards,

--
Mathieu Bruneau
aka ROunofF

===
GPG keys available @ http://rounoff.darktech.org