General design question - handling Billto and Shipto ID's Addresses 1

[molly]

I would like to see if I am doing this okay or not. I want to confirm the best manner of storing a BilltoID and a ShiptoId address.

I presently store 1,000 BilltoID's with 1 address each in table1. Then I have 1,500 ShiptoID's with 1 address each in table2.

I figure that i would make a main form with a pulldown combo box on the left for soldtoID and have an address travel in from table1. and then a different set to the right with another pulldown combo box for the shipto address pouring in from table 2.

I have looked at some models. they seem to have the BilltoID linked to a table1 like mine with one address. BUT the Shipto section is a Manual input section and not a table.

So is my method good? anything other address handling method there that i should look at?


Unrelated to my Order form, i want to mention that I also have a Contact table with many people who could get letters from us. so i have more address over in that table linked via the combined billto-shipto codes.

thanks you for reading this and giving suggestions before i proceed.
Molly

 

[kjv1611]

I'd suggest using a CustomerID that is associated with whatever BillTo and MailTo IDs so that you could just select the customer. Then, the Billto and MailTo addresses would populate from your Mailing and Billing tables. At least that would be my first thought on the matter. I personally like the idea of the data already being stored in a table, as apposed to having to manually enter the additional address, as that will eliminate human error, as well as eliminate some duplicate efforts or extra unnecessary work.

--

"If to err is human, then I must be some kind of human!" -Me

 

[lespaul]

I wouldn't even have two tables for shipping and billing, I would have one table for addresses and I would add a field indicating which one it is.
B - Billing
S - Shipping
and another code to indicate Billing & Shipping are the same address.


Leslie

Anything worth doing is a lot more difficult than it's worth - Unknown Induhvidual

Essential reading for database developers:
The Fundamentals of Relational Database Design
Understanding SQL Joins