Essentially what's happening is I'm allowing users to dynamically extend a couple of entities in the database through an easy-to-use graphical interface. The application dynamically generates the structure of forms and profiles based on records in the database. The primary motivation for this approach is that the application will be used by several different organizations that need to collect vastly different information from their clients. The only alternatives were much larger A and B entities full of fields that wouldn't be relevant to each organization's copy of the application, or to create and maintain separate models for each organization.
The two entities (let's call them A and B) are completely separate; there is no relationship between them as far as the current scope of the application is concerned. However, the way in which they are extended is exactly the same, resulting in duplicate tables such as this: http://img812.imageshack.us/img812/8329/currentv.png
This felt redundant to me, so I'm considering combining them like this: http://img51.imageshack.us/img51/1261/proposed.png
(The DynamicCategoryType entity was added because we need a way to collect the set of all possible fields for a given entity. We decided against a boolean in case we added a third entity, C, in the future, and we were advised to stay away from enums.)
Before I commit to either model, I'd like to get some feedback from some more experienced database designers. What are the primary pros and cons of each approach? Are there better ways to solve this problem?