Discussion, Using the example of people, businesses, and addresses, it depends how much unique information you gather about each entity.
Addresses for a person and a business probably share many related fields and would make logical sense that you could create one entity for just addresses. If the amount of information you gather about a business is relatively small, you can debate whether you should have one entity for both people and businesses as a new entity of "contact." You also have to look at the hierarchy of the application. If you business logic suggests that a business is higher in the hierarchy and not a peer level entity, then you can make a pretty good case for a business being separated out. If a business is at the same peer level of the hierarchy, you could make a case for or against either creating one entity with some extra fields or two separate entities that would add a little extra effort at integrity checking. Application scope, time available, and budget influence these decisions more than we like. We all want to create something easy to maintain, but we may not always have "maintainability" budgeted into the life-cycle. A shared repository for contact information does make it easier to keep uniform and comprehensive data. Teddy R. Payne, ACCFD Google Talk - teddyrpa...@gmail.com
