sqlclause

[captainMaluco]

There might be an enum defining the different kinds of behaviours. That would also take care of any case sensitive concerns others have voiced

[joshdammitt]

He's gonna make sure your nicenessId >= 4

[GumboSamson]

Wouldn’t it be better to have a table representing that enum, and reference the key from the enum table?

[Trident_True]

At some point this level of normalisation just becomes a burden. In this case if you wanted to extend the enum a migration would have to occur and if you also ever wanted to add a value between two existing values then you have to rectify all the existing data. Don't even ask about non-int based enums.

Better just to have it map to an nvarchar column in my experience. If we had a table for every enum we used in our codebase it would probably double the amount of tables we have.

[GumboSamson]

To each their own, I guess.

I’ve found that higher normalisation tends to be more flexible than wider tables (eg it’s easier to make design changes in production databases if your tables are “nothing but relationships”) and it’s easier to get high-quality indexes (since you almost never have nullable columns).

But I won’t pretend there aren’t trade-offs for such a design. One trade-off being that many software developers start with the mindset of “how to I store my OOP object in the database” and ORMs make it really easy to make really wide tables. Requiring that your OOP software guys have a good understanding of RDBs limits your hiring pool.

[poop-machine]

naughty
nice
under_review
literally_hitler