Best Way to Store Group Membership

[Paul.Pucciarelli]

So I have some 'groups' which 'users' can join. There is no
enrollment limit on these 'groups'. How should I store the list of
users enrolled in the group?

I'd like to be able to quickly determine the groups a user is in, and
the users in a group. Seems like a common problem but I can't come up
with an effecient solution.

[Jerry Stuckle]

Pa**************@gmail.com wrote:

So I have some 'groups' which 'users' can join. There is no
enrollment limit on these 'groups'. How should I store the list of
users enrolled in the group?

I'd like to be able to quickly determine the groups a user is in, and
the users in a group. Seems like a common problem but I can't come up
with an effecient solution.

A SQL database. For help on how to design the database, see the
appropriate database newsgroup.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Geoff Muldoon]

Jerry Stuckle says...

Pa**************@gmail.com wrote:

So I have some 'groups' which 'users' can join. There is no
enrollment limit on these 'groups'. How should I store the list of
users enrolled in the group?

I'd like to be able to quickly determine the groups a user is in, and
the users in a group. Seems like a common problem but I can't come up
with an effecient solution.

A SQL database. For help on how to design the database, see the
appropriate database newsgroup.

Most appropriately, yes, but you could put them in a file or files which
populate arrays if you absolutely had to.

And although off-topic, should be in comp.databases.mysql or similar ...

Users: user_id, user_desc, etc.
Groups: group_id, group_desc, etc.
Membership: group_id, user_id, etc.

Geoff M

[CJ Willcock]

Pa**************@gmail.com wrote:

So I have some 'groups' which 'users' can join. There is no
enrollment limit on these 'groups'. How should I store the list of
users enrolled in the group?

I'd like to be able to quickly determine the groups a user is in, and
the users in a group. Seems like a common problem but I can't come up
with an effecient solution.

Depends on whether the groups are a dynamic lot or a static lot. If the
number of groups is limited to a smallish number, say 32, won't change
and you don't mind the group names being hard-coded you can use this.
You can add new groups later without creating conflicts - to a limit.

Define a bunch of constants where each constant is a bit in a 32 bit
unsigned integer.

For example:

define( '_GROUP_DEBUGGER', 0x00000001 );
define( '_GROUP_THIEF', 0x00000002 );
define( '_GROUP_FIGHTER', 0x00000004 );
define( '_GROUP_MONK', 0x00000008 );
define( '_GROUP_MAGE', 0x00000010 );
define( '_GROUP_PHP', 0x00000020 );
define( '_GROUP_SQL', 0x00000040 );
....
define( '_GROUP_LIMIT', 0x80000000 );

However you choose to store the group mask, you will be able to test for
group membership with a bitwise AND and the named constant:

if( $user['group'] & _GROUP_PHP ) {
// do stuff for group member
} else {
// not a group member
}

Users can be in multiple groups and assigning group membership is easy:

$user['group'] = _GROUP_DEBUGGER | _GROUP_PHP | _GROUP_LIMIT;

To search for particular group members, just test for all users whose
group mask & _GROUP_XXXXX is not 0.
CJW

[larry]

If you plan to expand your project, I'd recommend go with the database
route of having a user, group and usergroup tables. I've done the
bitwise thing in the past, having to hard code group positions and
such into code but as the project grows and the uses for the groups
as well the hard coding can get out of hand.

With a table you could use real group name strings as IDs, just
validate new groups don't reuse existing group names.

The SQL queries are pretty simple

(lame Q&D SQL example)

"SELECT `group_name` FROM `usergroup` WHERE `user_id` = $userid"

To find users in groups:

"SELECT `user_id` FROM `usergroup` WHERE `group_name` = '$groupname'"

The bitwise thing is great when the capacity and databases scopes are
limited but if you have the space and capability, tables are easier to
deal with in the long-term.