Historical Considerations
The primary limitation of the OpenACS 3.x user group system is that it
-restricts the application developer to representing a "flat group"
+restricts the application developer to representing a "flat group"
that contains only users: The user_groups table may contain the
group_id of a parent group, but parent-child relationship
support is limited because it only allows one kind of relationship between
@@ -20,12 +21,12 @@
scope, user_id, and group_id columns
was used to identify the party. One disadvantage of this design convention is
that it increases a data model's complexity by requiring the programmer
-to:
add these three columns to each "scoped" table
define a multi-column check constraint to protect against data corruption
-(e.g., a row with a scope value of "group" but a null
+to:
add these three columns to each "scoped" table
define a multi-column check constraint to protect against data corruption
+(e.g., a row with a scope value of "group" but a null
group_id)
perform extra checks in Tcl and PL/SQL
functions and procedures to check both the user_id and
group_id values
The core of the Group Systems data model is quite simple, but it was
-designed in the hopes of modeling "real world" organizations which
+designed in the hopes of modeling "real world" organizations which
can be complex graph structures. The Groups System only considers groups that
can be modeled using directed acyclic graphs, but queries over these
structures are still complex enough to slow the system down. Since almost