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.
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.