Question

A colleague is adding a bit mask to all our database tables. In theory this is so we can track certain properties of each row across the entire system. For example…

• Is the row shipped with the system or added by the client once they’ve started using the system
• Has the row been deleted from the table (soft deletes)
• Is the row a default value within a set of rows

Is this a good idea? Are there other uses where this approach would be beneficial?

My preference is these properties are obviously important, and having a dedicated column for each property is justified to make what is happening clearer to fellow developers.

Answer 1

Not really, no.

You can only store bits in it, and only so many. So, seems to me like it’s asking for a lot of application-level headaches later on keeping track of what each one means and potential abuse later on because “hey they’re everywhere”. Is every bitmask on every table going to use the same definition for each bit? Will it be different on each table? What happens when you run out of bits? Add another?

There are lots of potential things you could do with it, but it begs the question “why do it that way instead of identifying what we will use those bits for right now and just make them proper columns?” You don’t really circumvent the possibility of schema changes this way anyway, so it seems like it’s trying to solve a problem that you can’t really “solve” and especially not with bitmasks.

Each of the things you mentioned can be (and should be) solved with real columns on the database, and those are far more self-documenting than “bit 5 of the BitMaskOptions field”.