Comments 5
Тут не все так просто. Enum - встроен в язык программирования и обычно на нем завязана бизнес логика в коде. Для C# это означает, что нельзя просто взять и добавить значение enum (aka добавить в таблицу). Потому что нет компилируемого кода, который будет обрабатывать новое значение enum-а.
Следовательно в данном случае - нет никакого смысла делать enum-ы как таблицы.
Но, когда вы начинаете оптимизации и переходите на нативный sql (например экран списка), то там появляются проблемы.
Чтобы отобразить текстовое описание enum-а - надо его подставить откуда-то. Если enum у вас на стороне C# - значит подмена будет на сервере или на клиенте. Но что это означает для пользователя? Сортировка по колонке сломается и будет сортировать по int значению, которое лежит в базе данных, а не по алфавиту для текстового описания.
Решить это можно переносом enum в таблицу БД и дополнительным джоином при выборке данных для экрана списка.
А там еще локализация на подходе...
И не очень понятно причем тут генерация и производительность ORM и нативного SQL.
Спасибо за обратную связь, очень приятно её увидеть от более компетентного человека!
Изначально передо мной встал выбор - что использовать: enum-ы (которые создаются в СУБД) или отдельную таблицу.
Основным аспектом для сравнения решил взять скорость выполнения запросов.
Пока изучал и делал замеры, решил их красиво оформить в таблички и написать статью о получившихся результатах.
Можете подсказать, какие моменты стоит учесть и рассмотреть, чтобы сделать данную статью максимально соответствующей теме и полно раскрывающей её? (Мне удобнее будет, если ответите в лс)
Они неизменяемы (да, добавить новое значение можно... но удалить ненужное уже трудно)
С добавлением тоже есть проблема: не все версии постгреса поддерживают изменение enum в транзакции. В том же ef core это ломает миграции.
Если в интерфейсе нужно показать лукап с типами, например для фильтрации счетов, то как быть? В случае с таблицей каждому типу можно хранить человекочитаемую расшифровку, что удобно для показа в ui.
Из своего опыта:
1) enum применять только в тех случаях, когда добавление нового значения влияет на изменение кодовой базы сервиса.
2) использование только внутреннее, без демонстрации пользователю. Чтобы, например, не заморачиваться с тем, откуда достать текстовое описание значения.
Если хоть одно из условий не выполняется, нужно использовать таблицы. То есть примерно в 99% случаев, если не больше
Что выбрать для типов моделей: Enums VS Tables?