user_group_types; one row for each different
type of user group, e.g., at a university you'd have a row for
the "committee" group type and a row for the "course" group type
user_group_type_fields; one row for each field that we must
keep for a user group type, e.g., for a university "course" group type
there would probably be rows in this table for
semester, meeting_times,
room_number, final_exam_p
user_groups; one row for each user group in a
community. At a university with 1000 courses per semester, 1000 rows
would be added to this table every semester. Note that these rows don't
store too much info about the groups, beyond their names (e.g., "CS 101,
Introduction to computer languages not used in industry"), whether the
group has been approved by the site administrator, and whether new
members must be approved.
*_info; one table for each user group type in a
community, each table named "${group_type}_info" (e.g., "course_info" or
"committee_info"). Each table will contain one row for each user group
of that type. So the course_info table would pick up 1000
new rows each semester. This is where the real information about a
group, the columns defined in user_group_type_fields are
kept.
user_group_map
before ACS 3.2: one row for each user in a group.
For example, in a university with 1000 courses, 30 students per
course, 30,000 rows would be added to this table each semester. The
user_group_map table also records a user's role in the
group.
ACS 3.2 and later: one row per each role played by a
user in a group. For example, in a small company where one person
plays both the CEO role and the CTO role, you would represent the
company as a user group of type "company", and there would be two rows
in user_group_map for that person, one with a value of
"CEO" in the role column and the other with a value of
"CTO".
user_group_map_queue; one row for each user who has
applied for membership in a group but whose membership has yet to be
approved
An example of something done consistently, however, is the recording of
whether or not a user is a system administrator of this site (tested
with the Tcl procedure ad_administrator_p). There is a
user group type of "system". One group of this type is pre-defined:
"administrators".
A university running one big ACS would have user group types of "committee" and "course". All the administrators on a committee would be in a user group of type "committeee". All the students and teachers in a particular course would be lumped together in a user group and could have a private discussion group. The teachers would have a different role within the user group and hence would have more access privileges.