Coming from a purely relational world, this might seem slightly weird at first. The pair (group_id, user_id) is sufficient to uniquely identify the object in question, so why have the redundant integer primary key? If you -take a closer look, it actually isn't quite so redundant. If you want to -be able to use the object model's permissioning features, and generic +take a closer look, it actually isn't quite so redundant. If you want to +be able to use the object model's permissioning features, and generic attribute features on a table, you need an integer primary key for that -table. This is because you can't really write a data model in oracle that +table. This is because you can't really write a data model in oracle that uses more than one way to represent identity.
So, this apparently redundant primary key has saved us the trouble of duplicating the entire generic storage system for the special case of the user_group_map, and has saved us from implementing ad-hoc security instead of just using acs-permissions. This design choice is further validated by the -fact that services like journals that weren't previously thought to be +fact that services like journals that weren't previously thought to be generic can in fact be generically applied to membership objects, thereby -allowing us to eliminated membership state auditing columns that weren't +allowing us to eliminated membership state auditing columns that weren't even capable of fully tracking the history of membership state.
The design choice of explicitly representing object identity with an integer primary key that is derived from a globally unique sequence is the key to eliminating redundant code and replacing it with generic object