Design the data structure for the application about innbyggerpanelet HOT 3 CLOSED

First iteration of potential structure.

Questions that need answering:

• Should the Candidate table either be related to the Trait table, or have a field for "trait relevancy grading". This will ensure that the status of the Candidate at the time of testing is historically correct if one were to go back and look (as User -> Traits is a living relation, not displayed here).

from innbyggerpanelet.

Suggestion:

Currently the Candidate interface defined in the shared library includes education, mother tongue, benefits, digital skills, etc. All of these can and should be defined as traits, as this will reduce the overall table size, and allow for easier expansion in the future.

For some of the fields there might be a concern to keep them exclusive from each other. One solution to this is adding "group" and "exclusive" fields to the trait table and using backend logic to ensure that no two exclusive traits in the same group can be related to a single user.

Additionally this will enable the creation of an administration panel for all traits. Although, deletion and updating of existing traits will have to be carefully managed.

from innbyggerpanelet.

Revision 3 (?):

Instead of defining the user profile with traditional fields (birthdate, occupation, skills, etc.) we will rather construct it from the related criteria (previously known as traits). Here is an example:

In this new version, the user profile only contains basic information such as name and address. All other information should be derived from the criteria table. This also means that the user will have to be regularly prompted to update this information.

The criteria table has also gotten some changes. Most notably the CriteriaCategory table which will divide the criteria into manageable groups and support exclusivity. To know if two traits are exclusive the exclusivitySlug field on Criteria will be used (if two traits share the same slug, they are exclusive).

Lastly, in order to keep data somewhat historically accurate a latestUpdate field will be added to the User table. In combination with the relevancyGrading field on the Candidate table, an administrator will be able to see the relevancyGrading of the Candidate at the time of the insight work, and also if traits have been changed since.

from innbyggerpanelet.