У цьому рецепті ми не будемо зупинятися на перевагах та недоліках використання enum на рівні коду. Натомість, ми розглянемо, як можна представити enum у базі даних. Під enum ми розуміємо набір рядкових значень, які може приймати певне поле. Розглянемо конкретний приклад для таблиці "users":
gender: MALE, FEMALE, UNKNOWN, NON_BINARYstatus: ACTIVE, BANNED, SELF_DELETEDВажливо відзначити, що список можливих значень визначається доменною моделлю, і, отже, буде змінюватися з розвитком проекту.
Можливі підходи:
1. Зберігати значення як varchar без перевірки на рівні бази даних, чи належить значення до enum.
2. Нормалізація даних. Для кожного enum створюється окрема таблиця у форматі id, value, яка використовується для зв'язку через foreign key. У основній таблиці зберігається не саме значення, а id з відповідної таблиці.
3. Enum на рівні бази даних. Більшість баз даних підтримують enum.
4. Довідник. Цей метод є проміжним варіантом між нормалізацією та використанням enum у базі даних. Таблиця-довідник об'єднує поля id та value в одне.
При виборі підходу, який підходить для конкретної ситуації, я звертаю увагу на:
1. розмір, необхідний для зберігання даних. Нормалізація та enum у базі даних зменшують обсяг.
2. простоту отримання даних. При нормалізації потрібні join-операції
3. легкість зміни enum. Простіше з довідником та при нормалізації, а enum-in-DB потребує міграцію.
4. необхідність перевірки на рівні бази даних. Можливо, перевірка не потрібна.
5. Забезпечення консистентності підходу в рамках проекту.
6. При нормалізації - який метод генерації id буде використовуватися: uuid, sequence, nanoid.
7. На останньому місці, але не менш важливе - яка база даних використовується?