
Pros and cons of different ways of storing Enum values in the database - fagnerbrack
https://zubialevich.blogspot.com/2019/08/enum-vaues-in-the-database.html
======
SigmundA
_The first pros I can imagine is, of course, size. Integer values will store
much less space on a hard drive than any string (4 bytes against 8 bytes per
symbol for varchar or 16 bytes per symbol for nvarchar)._

Uh varchar is 1 byte per "symbol" nvarchar is 2 bytes per "symbol" an int will
be larger than a 3 character varchar. Mixing up bits and bytes is not a good
sign.

 _Usually, enums are not having big lists of keys. The biggest enum I 've ever
seen was 300 key in it. which is only 3 symbols. I have rarely met enum names
with 3 or fewer symbols._

If its an int then its 4 bytes not 3 "symbols", if your storing string your
using the name not index. Seems like a point is trying to be made about 4
bytes int vs 3 byte varchar names but instead mixing int string size.

 _When you are storing enums as a string you are not depend on the order of
enums in code, so you can easily reorder them without any side affects. To
avoid this you can implicitly specify integer values for enums_

The opposite is also true when storing names instead of ints you can refactor
the name without changing the data. What do you do more often change enum
order or name?

Not a big fan of using enums anyway, I prefer some sort of coded value where
you store a short string code in the db that is human readable with a longer
description the users see, that way the description can be reworded if
necessary, you can also tack other metadata on to the code if necessary. Many
times the coded value is in the db as a table or even one table per coded
value with foreign keys so it can be modified and joined. Not as simple but
more flexible IMO.

------
abujazar
How about storing enum values as... enum values in the database?

