>>I am working on moving a 2.6 app to Sql 2005\Vb.Net. I have imported all of the tables and am in the process of adding additional needed fields, fixing some primary foreign key issues, changing field names etc.
>>
>>I did not want to change a whole lot of the structure of the table's as the data will need to be converted so I wanted to minimize that amount of work. however there are multiple tables that use multiple address fields. For instance the customer table has address, billing address and shipping address.
>>
>>So I am of course thinking that it would probably be better to create an address table to store all these pesky address's. Probably another table as well to store address types such as Main,shipTO, Billto etc.
>>
>>Can anyone think of a reason I shouldn't use this approach? Or have any suggestions
>>
>>
>>Thanks Alot
>>
>>Paul
>
>
>Paul,
>I can't think of a single reason not to create a separate address table. In "most" cases you will save storage space because "most" customers use the same address for address, billing address and shipping address ( or atleast two are the same and one is different). It will be more flexible and more normalized.
>
>I'd say go for it.
>
>Einar

I second the motion. One of the applications I support does it almost exactly this way. It does not have an AddressType field in the Address table. The lack of address type has never been a burden since we have never found a need to query for all MailTo's, HomeAddress, WorkAddress, etc. While I did not design the application, I fully agree that this was the right way to go.