The one denormalized table that does grow to be huge is the acs_object_party_privilege_map. However that's a problem that's much worse with Postgres, because of locking issues in PG within PL/pgSQL code. In Oracle I don't keep duplicate rows, but rather maintain a counter. But I can't properly lock within triggers in PG so have to keep duplicate rows (which occur due to the relseg/group model in particular, but can also occur elsewhere, there's no restriction on the number of times you can grant a party a privilege on an object).
This is particularly a problem for .LRN.
But ... despite this, we see surprisingly acceptable performance for sites like Galileo (I'm trying to gather some statistics now).
I'm still interested in the bitstring approach, but am still unsure it's worth the trouble.
Since the bitstring approach requires we reduce the number of privileges in the system and since this will speed permission checking somewhat, doing the reduction still seems like the first step.
Plus the code wouldn't be as stupid, frankly seeing packages define "foo-read" etc just looks stupid :)
Is an ownership field separate from creation_user really that useful? I'm suspicious of granting rights implicitly unless there's a very good reason to do so...
Also I think if we did a permissions audit of existing packages we'd find there's a fair amount of needless perms being granted. File storage seems particularly weird in this regard.
