dev775
asked on
Database Design for Contacts & Addresses
My database has four categories of contacts: customers, vendors, general contacts and employees, each stored in a separate table. I need advice on the most powerful method of managing addresses, some of which are US and some are foreign countries. Is there a benefit to using dedicated table just for addresses or should I include addresses in each table. How can I best accommodate addresses from different countries? How can I implement a zip code lookup?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Left this out: the field should be a bound Combo-Box with the Zipcode table as its source. Limit to list set to yes, so you can add the new zips.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks. These are helpful comments. Is there a resource that provides information on international address formats?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
mrihm - you have articulated my dilemma quite well. My reason for posting this question was to gain insight into a problem that thousands of others must have faced. I was hoping to learn how others have addressed (haha) this problem. Although my application is not that unique, my design objectives place much importance on the ability to generate powerful report scenarios, therefore the more available data the better. Thank you for your comments and the book reference. I am really hoping to find a template that reflects all of the fields that a universal (international) address table might contain. I can then build a very versatile UI (as Imoutwest suggested) to present the data in a user-friendly format.
If you are writing a multi country app then make sure all of your character fields are unicode.
So define them as NVARCHAR rather than VARCHAR.
This allows you to store every language in your database... japanese, arabic etc.
So define them as NVARCHAR rather than VARCHAR.
This allows you to store every language in your database... japanese, arabic etc.