An upcoming project of mine is considering a design that involves (what I'm calling) "abstract entity references". It's quite a departure from a more common data model design, but it may be necessary to achieve the flexibility we want. I'm wondering if other architects have experience with systems like this and where the caveats are.
The project has a requirement for a to control access to various entities (logically: business objects; physically: database rows) by various people. For example, we might want to create rules like:
- User Alice is a member of Company Z
- User Bob is the manager of Group Y, which has users Charlie, Dave, and Eve.
- User Frank may enter data for [critical business object] X, and also the [critical business objects] in [critical business object group] U.
- User George is not a member of Company T but may view the reports for Company T.
The idea is that we have a lot of different securable objects, roles, groups, and permissions, and we want a system to handle this. Ideally this system would require little to no coding for new situations once it's launched; it should be very flexible.
In a "traditional" data design, we might have entities/tables like this:
- User
- Company
- User/Company Cross-Reference
- UserGroup
- User/UserGroup Cross-Reference
- CBO ("Critical Business Object")
- User/CBO Cross-Reference
- CBOGroup
- User/CBOGroup Cross-Reference
- CBO/CBOGroup Cross-Reference
- ReportAccess, which is a cross-reference between User and Company specifically for access to reports
Note the big number of cross-reference tables. This system isn't terribly flexible as any time we want to add a new means of access we'd need to introduce a new cross-reference table; that, in turn, means additional coding.
The proposed system has all of the major entities (User, Company, CBO) reference a value in a new table called Entity. (In the code we'd probably make all of these entities subclasses of an Entity superclass). Then there's two additional tables that reference Entity * Group, which is also an Entity "subclass". * EntityRelation, which is a relation between two entities of any type (including Group). This will probably also have some sort of "Relationship Type" field to explain/qualify the relationship.
This system, at least at first glance, looks like it would meet a lot of our requirements. We might introduce new Entities down the road, but we'd never need to do additional tables to handle the grouping and relationships between these entities, because Group and EntityRelation can already handle that.
I'm concerned, however, whether this might not work very well in practice. The relationships between entities would become very complex and might be very hard for people (users and developers alike) to understand them. Also, they'd be very recursive; this would make things more difficult for our SQL-dependent report writing staff.
Does anyone have experiences with a similar system?