I would go with Steve's approach of using an Address table but keep in mind
winter seasonal addresses and the different logic for comparision (example
Dec thru Feb and today is Jan 5th) If populated they represent a seasonal
address. I would probably store the date range in 2 dates fields but the
concept is the same (you only care about the days and months because it's
the same every year). Also possibly an AddressType field storing a string
such as "business addresss", "home address", "summer home address" etc....
Also good to have a PrimaryAddress field that indicates which ONE address is
the primary mailing address. Only one record per member can be the primary
mailing address. Also Address2 and possibly Country.
See page 4 of this pdf file for a good screenshot:
http://www.missionresearch.com/giftworks/guides/giftworks2010/GiftWorks2010-WhatsNew.pdf
I'm not positive the best approach when querying, it sounds like this
company runs an update query to update the primaryAddress field
appropriately to set the ONE address that should be used for mailing. Then
you always just join to a query that selects the ONE primaryaddress record
for each member. There might be a better way for the querying end. It's
too late for me to think about a winter seasonal address or any address that
goes from one year to the next vs. an address that stays in the same year
and the extra complexity.
Hoping someone else answers this post I will probably need to do this one
soon myself.
My two cents,
Mark Andrews
RPT Software
http://www.rptsoftware.com