For years now, I've seen two sides to the discussion of how to handle enumeration data, especially in normalized databases. In most cases, enumerations need to be explicitly defined and understood by code for decision-making. Everyone seems to understand and agree on this point. This is when teh discussion diverges.
Side One
When that happens, may people make the argument that enumerations do not need to be in the database in a normalized table because the data can just be represented as a string or number/ordinal in the database, the same way it is represented in the code. This saves additional database work up front and allows database tools like hibernate to work more simply.
Side Two
The other side of the discussion says that enumerations represent defined data that sometimes warrants refactoring and migrations, and accomplishing said changes is much easier when data is normalized. Additionally, the other side says that we should be able to query detailed information that represents an enumeration so that I don't have to track what 'ENUM_XXX' means in some separate documentation.
I'm not trying to take a side in this debate as part of this post. Rather, I am just going to point out that JHipster has a very definite opinion on the subject. After generating enumerations and domain objects that use/include those enumerations using JDL / jdl-studio, it is immediately clear that JHipster follows Side One. There are no database objects representing enumerations, and all values that represent enumerations in the database are just replicas of the enumeration strings themselves.
Side One
When that happens, may people make the argument that enumerations do not need to be in the database in a normalized table because the data can just be represented as a string or number/ordinal in the database, the same way it is represented in the code. This saves additional database work up front and allows database tools like hibernate to work more simply.
Side Two
The other side of the discussion says that enumerations represent defined data that sometimes warrants refactoring and migrations, and accomplishing said changes is much easier when data is normalized. Additionally, the other side says that we should be able to query detailed information that represents an enumeration so that I don't have to track what 'ENUM_XXX' means in some separate documentation.
I'm not trying to take a side in this debate as part of this post. Rather, I am just going to point out that JHipster has a very definite opinion on the subject. After generating enumerations and domain objects that use/include those enumerations using JDL / jdl-studio, it is immediately clear that JHipster follows Side One. There are no database objects representing enumerations, and all values that represent enumerations in the database are just replicas of the enumeration strings themselves.
Comments
Post a Comment