A MySQL practitioner argues against using complex data types — specifically TIMESTAMP, DATE/TIME types, and ENUM — in favor of simpler numeric alternatives. The case against TIMESTAMP echoes Baron Schwartz's classic advice to store epochs in numeric fields. Against ENUM, the post cites Booking.com's experience (removing a value requires a full table rebuild) and a newly discovered MySQL bug where MIN()/MAX() on ENUM operates on string values while ORDER BY uses position values, creating inconsistent behavior that worsens when a secondary index is added.
Questions this post answers
Why should I avoid using ENUM in MySQL?
ENUM in MySQL has several surprising behaviors that make it error-prone. Removing a value from an ENUM definition requires a full table rebuild. MIN() and MAX() on an ENUM column operate on the string value, while ORDER BY uses the numeric position — creating inconsistent results. Adding a secondary index on an ENUM column can even change the result of MIN()/MAX() queries (MySQL Bug #121036). Using a numeric column instead avoids all of these pitfalls. Developers designing MySQL schemas track gotchas like these on daily.dev before they become production incidents.
Why is storing timestamps as integers better than using MySQL TIMESTAMP type?
MySQL's TIMESTAMP type carries timezone-related complexity that is easy to misunderstand, and the behavior can differ across server configurations and team members' expectations. Storing epoch values in a plain numeric (integer) column eliminates timezone conversion surprises entirely. This recommendation was popularized by Baron Schwartz, who compared using TIMESTAMP to 'running with scissors', and it remains a widely held MySQL best practice. Teams migrating away from TIMESTAMP columns find the broader MySQL schema discussion on daily.dev useful for building consensus.
176.6K Impressions13 Comments