The nature of the application implies that it ought to be entirely data-driven. That is, the operations one can apply ought to be a function of the state (i.e., a FSM). Currently, there are a number of hardcoded assumptions (e.g., how project years are loosely defined, how each project year has exactly three rotations, roles and permissions, etc.) that would be better defined in the database. For this, the schema needs to be enriched appropriately.
Moreover, while the ORM use has provided a degree of data normalisation, this isn't used productively. For example, certain queries could be optimised with joins executed by the database, rather than by programmatically computing the Cartesian product. I'm also not convinced that the ORM, by default, generates the most efficient indices.
Finally, there may be instances where non-relational data is stored, which may be better served by a different data model DBMS (in conjunction with the RDBMS).
The nature of the application implies that it ought to be entirely data-driven. That is, the operations one can apply ought to be a function of the state (i.e., a FSM). Currently, there are a number of hardcoded assumptions (e.g., how project years are loosely defined, how each project year has exactly three rotations, roles and permissions, etc.) that would be better defined in the database. For this, the schema needs to be enriched appropriately.
Moreover, while the ORM use has provided a degree of data normalisation, this isn't used productively. For example, certain queries could be optimised with joins executed by the database, rather than by programmatically computing the Cartesian product. I'm also not convinced that the ORM, by default, generates the most efficient indices.
Finally, there may be instances where non-relational data is stored, which may be better served by a different data model DBMS (in conjunction with the RDBMS).