Почему тип поля enum на уровне базы — зло

Часто разработчики интересуются почему не рекомендуется использовать тип поля enum в базе данных, и в этой статье мы рассмотрим все плюсы и минусы данного типа.

Тип колонки enum используется для хранения данных, которые могут принимать определённые значения из заранее определённого набора. Он обеспечивает ограничение значений, которые может принимать колонка, и позволяет более строго контролировать данные. Это может быть полезно для хранения статусов, категорий, типов или любых других значений, которые могут быть заданы только из ограниченного набора вариантов.

Но это в теории. А что на практике? Давайте рассмотрим.

Допустим у нас есть таблица со списком платежей, содержащая колонку status со следующими значениями:

CREATE TABLE `payments`(     `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,   `status` ENUM('new', 'progress', 'done', 'fauled') NOT NULL,    KEY(`id`) ) CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Через какое-то время была замечена грамматическая ошибка в слове «failed» и принято решение её исправить.

Нюанс изменения enum поля в том, что при его редактировании сбрасываются значения колонки в null для всех строк таблицы, а то и вовсе получим ошибку Data truncated for column 'status' at row 3. То есть, чтобы корректно изменить enum поле, нужно куда-то сохранить данные. План действий будет таков:

1. Создать новую enum колонку с правильным набором данных;

2. Скопировать значение из старой колонки в новую и сразу применить исправление значения;

3. Удалить старую enum колонку;

4. Переименовать новую enum колонку.

При использовании фреймворка Laravel это будет выглядеть следующим образом:

use Illuminate\Database\Migrations\Migration; use Illuminate\Database\Schema\Blueprint; use Illuminate\Support\Facades\DB; use Illuminate\Support\Facades\Schema;  return new class extends Migration {     public function up(): void     {         // Создаём новую колонку         Schema::table('payments', function (Blueprint $table) {             $table->enum('tmp_status', ['new', 'progress', 'done', 'failed']);         });          // Копируем значения из enum колонки в новую с корректировкой значения         DB::statement('UPDATE payments SET tmp_status = (IF status = \'fauled\' THEN \'failed\' ELSE status END IF)');          // Удаляем старую колонку         Schema::table('payments', function (Blueprint $table) {             $table->dropColumn('status');         });          // Переименовываем колонку         Schema::table('payments', function (Blueprint $table) {             $table->renameColumn('tmp_status', 'status');         });     } };

На языке SQL эти действия будут выглядеть следующим образом:

ALTER TABLE `payments`   ADD COLUMN `tmp_status` ENUM('new', 'progress', 'done', 'failed') NOT NULL AFTER `status`;  UPDATE `payments` SET `tmp_status` = (     IF `status` = 'fauled'     THEN 'failed'     ELSE `status` END IF );  ALTER TABLE `payments`   DROP COLUMN `status`;  ALTER TABLE `payments`   CHANGE `tmp_status` `status` ENUM('new', 'progress', 'done', 'failed') CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci NULL;

При использовании фреймворка Laravel нельзя просто взять и применить метод «change» на поле типа enum.Это вызовет ошибку:

Unknown column type «enum» requested. Any Doctrine type that you use has to be registered with \Doctrine\DBAL\Types\Type::addType()…

Для решения этой проблемы приходится применять следующий костыль перед применением изменений:

protected function fixEnum(): void {     $platform = Schema::getConnection()->getDoctrineSchemaManager()->getDatabasePlatform();     $platform->registerDoctrineTypeMapping('enum', 'string'); }

И, кроме этого, всё равно нужно будет на стороне приложения обрабатывать значение либо как константу класса, либо как enum класс. Например:

class Payment extends Model {     protected $casts = [         'status' => StatusEnum::class,     ]; }  enum StatusEnum: string {     case New      = 'new';     case Progress = 'progress';     case Done     = 'done';     case Failed   = 'failed'; }

А теперь представьте, что как только эта задача выполнена, пришла новая — добавить новый статус — Refund…

Альтернатива этой боли — отказ от полей БД типа enum в пользу integer. В этом случае как при изменении названия, так и при добавлении нового всё что нужно будет сделать — это изменить содержимое самого enum класса. Например:

// До enum StatusEnum: int {     case New      = 0;     case Progress = 1;     case Done     = 2;     case Fauled   = 3; }  // После enum StatusEnum: int {     case New      = 0;     case Progress = 1;     case Done     = 2;     case Failed   = 3;     case Refund   = 4; }

И всё. Никакой боли и задача закрывается буквально за несколько секунд.

Именно поэтому многие разработчики отказываются от использования колонок типа enum в базе данных сохраняя не только время, потраченное на задачу, но и нервы и, в качестве приятного бонуса, шанс потерять данные сводится к нулю.

Также можно ответить на вопрос «почему integer, а не string»: дело в том, что поля типа string подвержены грамматическим ошибкам и всё что они дают — это удобство чтения таких данных в одной конкретной таблице без использования SQL запросов с применением JOIN функций. Но если в слове будет допущена ошибка или слово нужно будет заменить на другое — придётся отправлять запрос в базу, чего не нужно делать при использовании целочисленных значений.

Таким образом, тип полей enum в базе является иррациональным и бессмысленным действием за исключением крайне редких и специфичных кейсов.

Заключение

При всём этом, необходимо всегда валидировать данные перед записью в базу даже если используется тип колонки enum, иначе высока вероятность поймать 500-ю ошибку от базы вместо корректной обработки.

В том же Laravel правило валидации реализуется очень просто:

public function rules(): array {     return [         'status' => [Rule::enum(StatusEnum::class)],     ]; }

И на выходе, в случае обнаружения проблем, получим корректный код четырёхсотой серии с расшифровкой вместо `500 Whoops! Something wrong`.

Это крайне удобно и максимально практично.