8 ms·
Yeah, maybe I'll update the post and mention ENUMs. I like the type safety of ENUMs, and I'm actually using them in my application, but they can cause a lot of
by felixge 9y ago
Yeah, maybe I'll update the post and mention ENUMs.
I like the type safety of ENUMs, and I'm actually using them in my application, but they can cause a lot of problems. E.g. it's currently almost impossible to remove an ENUM value [1], and adding a new value can't be done inside of a transaction.
The state transitions could definitely go into a table, but I feel it's overkill in many cases, and would have probably obfuscated the main ideas presented in the article.
Anyway, thanks for your feedback. There is definitely a lot more to explore for anybody who is interested in applying these ideas in practice :)
[1] https://www.postgresql.org/message-id/21012.1459434338%40sss.pgh.pa.us https://www.postgresql.org/message-id/21012.1459434338%40sss...
- ysleepy 9y agoHm, I didn't know that about enums. In the end it is just quibble about style anyway and one usually end up with what is measured faster in testing..
- jerrysievert 9y agobut if you were to push those states into a table, you'll likely end up with degraded performance due to the joins. I agree with your comments about ENUMs, though, especially having built many "static" products that suddenly need their ENUMs changed, and having a group of developers visiting me and asking why it's not as possible as they had assumed :)