| 2015-12-03 08:26:15 |
Aaron Wells |
description |
Mahara has a few prominent awkward database structures, that can be considered examples of polymorphism and/or inheritance, in the data structures we store in the database.
Some of the awkward tables:
1. The parallel tables for each plugintype: artefact_installed, blocktype_installed, etc; artefact_cron, blocktype_cron, etc...
2. The multiple "owner" tables in the "view" table: view.owner, view.group, view.institution. This one has actually caused bugs so far, due to the need to make these columns nullable foreign keys, making it difficult to enforce the correct uniqueness constraint on some of the other columns.
3. If we ever get around to implementing artefact permissions, and/or multiple collections per page, we'll have a similar situation with the "view_access" table.
So far we've either copied Moodle or taken an ad-hoc "reinvent the wheel" approach to this issue. But there are actually a few known strategies for dealing with these situations, each of which has its own advantages and disadvantages. I think it would be good to summarize those into a table in the developer section of the wiki, so that we can make a more informed decision when implementing such tables in the future, or considering to refactor the existing tables. |
Mahara has a few prominent awkward database structures, that can be considered examples of polymorphism and/or inheritance, in the data structures we store in the database.
Some of the awkward tables:
1. The parallel tables for each plugintype: artefact_installed, blocktype_installed, etc; artefact_cron, blocktype_cron, etc...
2. The multiple "owner" columns in the "view" table, which represent the different types of entities that can own a view (or collection, or artefact): view.owner, view.group, view.institution. This one has actually caused bugs so far, due to the need to make these columns nullable foreign keys, making it difficult to enforce the correct uniqueness constraint on some of the other columns.
3. If we ever get around to implementing artefact permissions, and/or multiple collections per page, we'll have a similar situation with the "view_access" table.
So far we've either copied Moodle or taken an ad-hoc "reinvent the wheel" approach to this issue. But there are actually a few known strategies for dealing with these situations, each of which has its own advantages and disadvantages. I think it would be good to summarize those into a table in the developer section of the wiki, so that we can make a more informed decision when implementing such tables in the future, or considering to refactor the existing tables. |
|
