Вход на сайт

Просмотр новости

Найдите то, что Вас интересует

MySQL Best Practice : not using date / time types, nor ENUM

Дата публикации: 30-07-2026 15:46:44

Today, I was reminded of a MySQL Best Practice, probably generalizable to all databases : using simple types, not complex types.  Such complex types to avoid include the date and time data types (including TIMESTAMP) and ENUM.  Let\'s see why.
A little history about this, Baron Schwartz, a MySQL Legend who is not involved in the community anymore, compared using the TIMESTAMP type to
MySQL Best Practice : not using date / time types, nor ENUM appeared first on MariaDB.org


Основное содержимое страницы с новостью.

Today, I was reminded of a MySQL Best Practice, probably generalizable to all databases : using simple types, not complex types.  Such complex types to avoid include the date and time data types (including TIMESTAMP) and ENUM.  Let's see why.

A little history about this, Baron Schwartz, a MySQL Legend who is not involved in the community anymore, compared using the TIMESTAMP type to running with scissors.  His blog is gone, but the Wayback Machine has a copy of his post from February 2014.  His advice : storing epochs in a numeric field !

Also at Booking.com, we stopped using the ENUM type.  One reason was because of their complex behavior, including removing a value having to rebuild the table.  Using a numeric value instead of an ENUM was the best practice there (more about ENUM below).

The more general reason for not using complex / high-level types : you probably do not fully know how they behave.  And if you think you master them, you are probably wrong.  And in the unlikely case where you fully understand them, your colleagues will not.  Time zones are complicated, which explains TIMESTAMP, but ENUM looks simple, no ?

And this brings me to the Today I Learned moment of the day : I did not know that MIN and MAX on ENUM is on the String value, not on the numeric / position value (ORDER BY is on the position).  I learned that via Bug #121036: Creating a secondary index on an ENUM column changes the result of MIN()/MAX().  Could you imagine having to rebuild an index when changing an ENUM ?  Me neither !

So do not use ENUM, nor SET, nor TIMESTAMP !

And as Baron wrote : Enjoy all the spare time you’ll have to do actually useful things as a result.

Схожие новости

#Наименование новостиТональностьИнформативностьДата публикации
1Do not uselessly grant CREATE and ALTER TABLE09.1120-06-2026
2Symlinks are Unsafe since MySQL 8.0.39 (and maybe even before)08.2314-04-2026
3Inserting in Two Tables in a Single Round-Trip with JSON Duality Views in MySQL 9.705.9904-06-2026
4Performance Progression of Percona Server for MySQL 8.4010.7227-08-2026
5Stored Procedures memory consumption in Percona Server for MySQL05.431-07-2026
6MariaDB Contribution Statistics, January-June 2026011.0325-08-2026
7MySQL 8.0.17 GTID Crash Safety Improvement09.2104-08-2026
8MySQL 26.7 Moves the Thread Pool Plugin to Community Edition09.2922-08-2026
9Understanding MySQL Replication “fatal error 1236”: “Replica has more GTIDs than the source has, using the source’s SERVER_UUID”08.1303-08-2026
10MariaDB Community Server Q3 2026 maintenance releases018.6324-08-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 6.63. Источник: mariadb.org.