This appears to be a significant design flaw.
The first question is would address be considered an entity, or is address really an attribute of Other
entities? :Salesman has address" would be the verb phrase. Not "address has salesman or district manager or..". In this case, there should probably be a table to store the addresses for each entity. You could argue that this is repeating data because "123 Main St" is contained over and over, but you can also argue that it is not repeated because it is associated with many different entities.
Think of a name. Many people can have the name "Michael", but we don't normally create a table of first names, and try to create a relationship between the first name table and many other tables in a database.
The second question is, if address is indeed an entity on it's own, then lookupid and record type should probably not be in the address table.
These should be moved into a separate set of tables that resolve the many to many relationship between the address table and the rest of the tables.
So, you will have the address table, the salesman, district manager etc. etc. tables, and a separate table such as Salesman_Address that contains the primary key of the salesman, the primary key of the address, and if required, an address type lookup.
Sorry for all of the theory but I just spent the better part of this morning diagnosing, tuning and patching a really bad query based upon a really bad design that is identical to your design. This table, as well as any code that uses it, have been one of the biggest sources of deadlocks and bottlenecks in the system. I would not want to wish the work required to remove this design on my worst enemies!
Michael L JohnIf you assassinate a DBA, would you pull a trigger?
To properly post on a forum:http://www.sqlservercentral.com/articles/61537/