The OpenOLAT data model to define group and course memberships has grown historically. It is modeled using the SecurityGroup construct and uses permissions that are persisted in the database but actually never queried during runtime.
The biggest problem of the data structure is the fact that course ownership, course coaches, course participants, group coaches and group participants are all individual queries. Prior to OpenOLAT 10 we tried to deal with this situation by making complex views that join all the possibilities together, however it was not possible to do this perfect for all databases and performance went down badly with to many relations. Those queries have to be made when the portal is show, right after login. It is critical to reduce the load of the login process.
In OpenOLAT 10, we want to show even more data and combine personal performance data with the list of relevant courses. This makes the queries even more complex and time consuming. At some point we decided that no more optimizations are possible, we need to fix the underlying problem, which is a very suboptimal data structure.
In OpenOLAT 10 we therefore introduce an all new datastructure to replace the SecurityGroup and its permissions completely in the long run. The new Group construct is a security construct that holds members and defines the type of membership in the membership relation table. Courses reference only those group objects (via repository entry). BusinessGroups also have only a reference to one Group object. Now, all relations to a course - either explicit members or implicit via a BusinessGroup membership - can be queried with one single and simple query.