User database design #226

Closed
opened 2026-04-10 10:21:14 +00:00 by a24vinla · 10 comments
Collaborator

We need to design the database containing all user info. We also need to determine what should be stored. Should the layout config files also be stored in this DB?

Related Issues: #221 #148 #143

We need to design the database containing all user info. We also need to determine what should be stored. Should the layout config files also be stored in this DB? Related Issues: #221 #148 #143
Collaborator

V1 ER diagram

bild

# V1 ER diagram ![bild](/attachments/d02f050f-26e0-4be2-ae12-357b15ca4072)
142 KiB
Collaborator

A list of possible things that the database should contain can be located at #221 (comment). Don't be afraid to add as you see fit.

A list of possible things that the database should contain can be located at https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/221#issuecomment-1858. Don't be afraid to add as you see fit.
Collaborator

V2 ER diagram

bild

# V2 ER diagram ![bild](/attachments/cad5c7ca-f222-4e1f-8aba-30c6a10a2ec1)
145 KiB
Collaborator

bild

![bild](/attachments/56499446-7c82-4a68-95ee-ffe2dd8c6b3d)
86 KiB
Collaborator

ER and UML diagrams look good, everything seems to be included from issue #221.
The "recent layout" in the table user seems to be missing from the UML, as well as grid settings in layout.

ER and UML diagrams look good, everything seems to be included from issue #221. The "recent layout" in the table user seems to be missing from the UML, as well as grid settings in layout.
Collaborator

The diagrams looks good, however I have some pointers,

In Usersettings, you are storing data that already is being stored in User, such as email and LName. These attributes don't really belong in a settings menu. I am not entirely sure but this might also break normalization rules, since you are basically duplicating the dependency UserID -> Email/LName across two tables which introduces redundancy and could create a transitive dependency which would break 3NF.

And something small would be even in a diagram try to stick to the conventions that have been made since whoever does make the database might follow the diagram quite closely which currently breaks the conventions stated here.

For example in the diagram we have FName which does not follow our naming conventions of using lowercase letters and underscores (e.g, first_name) We are also supposed to avoid abbreviations where its possible.

The diagrams looks good, however I have some pointers, In Usersettings, you are storing data that already is being stored in User, such as email and LName. These attributes don't really belong in a settings menu. I am not entirely sure but this might also break normalization rules, since you are basically duplicating the dependency UserID -> Email/LName across two tables which introduces redundancy and could create a transitive dependency which would break 3NF. And something small would be even in a diagram try to stick to the conventions that have been made since whoever does make the database might follow the diagram quite closely which currently breaks the conventions stated [here](https://git.webug.se/Andras/BoundlessFlowCampus2K/wiki/SQL-Standards). For example in the diagram we have FName which does not follow our naming conventions of using lowercase letters and underscores (e.g, first_name) We are also supposed to avoid abbreviations where its possible.
Collaborator

A question regarding mail/lname stored in usersettings, are they there to update mail/lname? Should these be functions instead?

A question regarding mail/lname stored in usersettings, are they there to update mail/lname? Should these be functions instead?
Collaborator

Try to always provide the draw.io .zip file in the issue in case changes need to be made to the model.

Try to always provide the draw.io .zip file in the issue in case changes need to be made to the model.
Owner

Since making changes to database after we have committed code is complicated.... take your time to "future-proof" the database design.

Since making changes to database after we have committed code is complicated.... take your time to "future-proof" the database design.
Collaborator

This has been implemented . I close this issue.

This has been implemented . I close this issue.
Sign in to join this conversation.
No milestone
No project
6 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Andras/BoundlessFlowCampus2K#226
No description provided.