Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactoring images table in database #116

Open
Kamieljv opened this issue Jun 28, 2024 · 0 comments
Open

Refactoring images table in database #116

Kamieljv opened this issue Jun 28, 2024 · 0 comments
Labels
enhancement New feature or request priority:low Low priority

Comments

@Kamieljv
Copy link
Owner

Comment by @YasinKaryagdi:

I would actually suggest redoing this table in the following way:
remove attributes user_id, organizer_id, actie_id, report_id, referentie_id, these
create a lot of redundant data. I assume that what we are trying to convey here is
that this image belongs to a certain thing, a better approach tho would be what is
already currently implemented, we store the images key in the related table. We
currently have an image attribute in the related tables (so the image attribute, or the
logo attribute or the avatar attribute). Now we are doing things twice, we are storing
the image in the image table and pointing to what it belongs to, but we also point
towards the image table via the other table. A better approach would be to have the
key of the image table as a nullable foreign key in the related tables. This way if there
is an image related to some user for example we can store the key of that image in
the user table and then still get access to it, this way you also ensure that an image
exists since the DBMS validates foreign key constraints. Also we might have images
that are not related to any one thing or we might have that an image is related to for
example multiple acties. If this is the case then we don’t need to store the same
image multiple times, we just point at the same image within different rows of the
acties table.
If these changes are done then key would probably be the new key, idk for sure tho.
Theoretically you could also convert this into many small relation tables where the
new tables consist of two foreign keys, one for the key of the image table and one for
the key of the related table, so each removed attribute (user_id, organizer_id,
actie_id, report_id, referentie_id), would get it’s own table.

@Kamieljv Kamieljv added enhancement New feature or request priority:low Low priority labels Jun 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority:low Low priority
Projects
None yet
Development

No branches or pull requests

1 participant