Is breaking the atomicity rule justified here?
working one a side project and i came across a problem , i want users to save to their profile their preferred colors, user can have one or multiple preffered colors , the good way to do it is to just have a separate table UserPreferredColors
but im thinking, since its use case will be very limited why waste a whole table for that, maybe just add it to the user table as column where the value is a list, the colors will not be detailed, there isnt specific hex or names just a standardised list of colors the user can select one or multiple like this screenshot i took from Color Hunt
but im thinking, since its use case will be very limited why waste a whole table for that, maybe just add it to the user table as column where the value is a list, the colors will not be detailed, there isnt specific hex or names just a standardised list of colors the user can select one or multiple like this screenshot i took from Color Hunt
19 Replies
why the colors exist in the first place?
so to add more context, on the utility of this either column or seperate table,
so in the feed system, posts will have properties like describtion and all the standard solcial media posts, but it will also have dominating colors, and based on the user color preference we will push certain posts higher, so the backend is very affected by this decision since it is responsable for filling the user feed
sounds like a tag system, not gonna lie
yea it is
why not just have a table with colors for the tags or something?
i dont understand, where is the link to the user or the post
nowhere
it's a tag system
you have tags, and each post has multiple tags
and each tag has a color
i still dont get it, is a tag system a design patern i dont know about
it's just tags
just like in a blog post
yea but how does it link back to the user prefering certain tags
a user tag preference table or a json array
yea i know that much but which one to use
users don't update tags that often, so, an array may be enough
i see, thank a lot, also generalising it to a tags table makes a lot more sense than what i had before so thanks for that too
you're welcome
Nobody seems to have mentioned it so I will, this is NOT an atomicity problem, this is normalization problem, very different things.
This tag system is generally what we call a many-to-many relationship with a JUNCTION TABLE, basically you have one table for idk, user posts or whatever, a table for tags AND the junction table that connects them both; This is completely normalized and avoids duplicated data HOWEVER, it can be costly if you're constantly accessing this data
but for small apps is aight
so i learned this stuff a while ago and in french so forgive me if something was lost in the translation, but i know there is atomicity in database transactions, but also in normalisation the Atomic values (from first normal form) about whether a column contains a single indivisible value
ah that's a different concept and never heard it called "atomicity" before, just call it normalisation cause atomicity is database transaction stuff
regardless, same answer, just use a junction table
that said, don't think everything has to be normalized in your db, using JSON isn't uncommon now that dbs have gotten a lot better at manipulating it
got it, thank you so much