On one of my sites, I have a main Users table with each user’s unique user id, e-mail address, password, etc.
I need to start keeping track of a lot of binary flags related to each user, such as whether they have confirmed their e-mail, whether they have posted a message, whether they have upgraded their account, whether they have done X, whether they have done Y, etc.
Each of these flags is a simple “0” (false) or “1” (true), and based on these flags, my site shows the user or does different things.
My question is, does it make more sense to add these binary flags to the main Users table or to create a separate table for the binary flags or something else?
Please try to explain your reasoning (and the advantages of your approach) so that I understand where you’re coming from.
Do all these flags need to be stored or they can be calculated? For example, if user hasn’t posted any message, this can be easily determined by querying the MESSAGE table.
Physically storing “calculable” flags is redundant and opens the possibility for data inconsistencies. For example what if user adds a message but a bug in your application prevents the flag update? Such “denormalization” may be justified for performance reasons, but only make this decision after you have measured the performance on realistic amounts of data and representative workloads.
OTOH, some flags may be “real” (e.g. whether the user has confirmed the e-mail). If such flags are relatively static (i.e. you know them in advance, at the time you are designing your data model), store them directly as simple boolean (or equivalent) fields in the USER table itself.
Only if you need to have a considerable run-time flexibility, consider using a separate FLAG table that is in N:1 relationship with USER table. This is a kind of EAV.