In designing a MySQL schema, should I avoid using an
enum type altogether, as I have been reading really strong, but favored opinions on this subject, such as:
- Stackoverflow post on efficiency of enum vs a join
enumis data, not code
- Blog: Reason why MySQL's enum data type is evil
- Right time to use an
Or, is there a choice to be made specific to the use case in hand? If there is, what decision framework should I use, i.e. when to choose one of the two options?
Currency: It's better to use a table join, since currency codes to be supported could change with time (since modification has been emphasized in many posts as anti-enum, but then what could not change with time?).
PaymentStatus: It's better to use
enumtype with values like,
TierPlans: It's better to use a table join, as it would give the flexibility to add columns like monthlyPricing, annualPricing, discountRate, etc. in the future. (I am currently using
enuminstead, with values like
MASTER; hadn't thought of pricing yet -_- ).
I am finding that if I stress enough, I could find a table join being a better choice always, mutation safe route. Is increasing number of tables or table joins a symptom of bad design? How should I approach design in general, and design in such use cases specifically?
Note: I had asked this question on SO here. I am posting it here since I see that there is a closing request there, and I desperately need an answer to this confusing roadblock of mine. Understandably this might not be a good question to ask here too. I'd rather edit, if you may guide!