User database design #226
Labels
No labels
_CRITICAL_
API
app
backEnd
Blocked, waiting for further changes
bug
cleanup
close
design
duplicate
enhancement
feature request
frontEnd
help wanted
invalid
low priority
needs input
needs review
project documentation
question
research
reviewed
script
security
SQL
style
testing
topLevel
wontfix
No milestone
No project
6 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Andras/BoundlessFlowCampus2K#226
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
V1 ER diagram
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.
V2 ER diagram
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.
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.
A question regarding mail/lname stored in usersettings, are they there to update mail/lname? Should these be functions instead?
Try to always provide the draw.io .zip file in the issue in case changes need to be made to the model.
Since making changes to database after we have committed code is complicated.... take your time to "future-proof" the database design.
This has been implemented . I close this issue.