>I must have Customer and Vendor in separate tables. So if I have a
>separate Address table, I should use uniqueidentifier (GUID) as the
You could generate a identity id in the address table and use that
in both customer and vendor tables.
From a database point of view I probably would do with and Customer
and an Vendor table and not use an address table. Except if you have
a reason to go with the address table. The amount of redundance is
very limited because most customers are not vendors.
From an OO point of view, you could reason that the address is common
to both vendor and address, that you have functionality on the address
and do not want to build that functionality twice so create a
sepperate address table. (First offcourse going through class design
etc. and then implementing the class design).
Generate an identity in the address table and use this as join field
or you could even use this as a referential constraint field. An
address can be from more than one customer/vendor if you want this,
but you this doesn't need to be.
From a performance point of view, this could work both ways. If you
use the tables a lot without an huge address, leaving out the address
might give an performance advantage. If you always use the address or
part of the address, keeping it in the tables might lead to a
performance advantage. (Probably performance is not an issue here).
From the application point of view, this you have to fill in yourself.
If you do not have sepperate functionality on a address store it
within the customer and vendor tables. Even if you need functionality
on addres you probably could make a view where you can select the
addressfields of both tables and do a union on that.