Don,

IMHO for your scenario, where it can be assumed, that there is a limited number of persons, who shall be in a group, it would be preferable to have a buddies table (ID, owner, buddy, bRole) with bRolee = (Partner, Family, Friend, Business Associate, ...) where grantees are stored. Your application need to provide an option to add users to those predefined roles and evaluation can either be done in your app directly against this table or e.g. page permissions are copies as user (not role!) permissions for each role member. Especially for those fairly populated associations, bitfields are not efficient in regard of storage.

Don,

in my approach, there is NO DotNetNuke role called "Business associates". Instead, roles are personalized by author ("my buddies") and access to controls is verified against both users records, the owner and the visitor to get the correct permission. Only, if you need to use DotNetNuke security (e.g. for tab access), you are replacing the personalized roles by individual user permission.

Okay...  This seems like such an obvious thing to me, but nobody else has mentioned it so I'm probably missing something obvious...

Why not store role information in the session?  If you're talking about 4k, even if you have 10,000 users in a 20 minute period of time, you're only talking about 40megs of ram on the server for role information...  but most users wouldn't be anywhere near 4k of roles, and this is only relevant for users who have logged in!