>>If you share the address table, you could identify the type of address table record with a code (E for employee C for customer). If the address table also includes the header information, you could link it to the contacts table (if the address table actually contains more information than just the address) for both customers and employees. Not sure by your description if the address table only includes addresses and nothing more.
>
>Here is the exact point where one has to wrestle with normalization: Isn't it possible for an employee to be a customer as well ?
>Giving letters easily leads to the denormalized side - at least as long as they are not keys into a lookup table, where "buying Employee" can easily be added. The other option which is in less danger being tainted IMHO is to give each option its own field: isEmployee, isCustomer and so on.
>[I consider the "least denormalized" version of having a M:N table describing links and adress types in most situations to be overkill...]
>
>regards
>
>thomas

I agree :o)