Перечисления в DB или НИКАКИЕ перечисления в DB
Реальный вопрос, "Что является единственным самым эффективным способом быть Slashdotted"
, Если это - настоящая проблема, перенаправьте трафик на мой сайт.
6 ответов
Я сделал и то, и другое, но теперь я предпочитаю определять их как классы в коде.
Новые файлы ничего не стоят, и преимущества, которые вы получаете от их наличия в базе данных, должны обрабатываться как бизнес-правила.
Кроме того, я не люблю хранить данные в базе данных, которые на самом деле не меняются. И похоже, что перечисление подходит под это описание. Для меня не имеет смысла иметь таблицу поиска состояний, но класс перечисления состояний для меня имеет смысл.
Если его нужно поддерживать, я бы оставил их в таблице поиска в БД. Даже если я думаю, что их не нужно поддерживать, я бы все равно пошел к таблице поиска, так что, если я ошибаюсь, это не имеет большого значения.
РЕДАКТИРОВАТЬ:
Я хочу уточнить, что если Enum не является часть модели БД, то я оставляю ее в коде.
Я поместил их в базу данных, но я действительно не могу защитить , почему я это делаю. Это просто «кажется правильным». Думаю, я оправдываю это тем, что всегда есть "правильная" версия перечислений, проверяющая базу данных.
Зависимости схемы должны храниться в самой базе данных, чтобы любые изменения в вашей архитектуре можно было легко выполнять прозрачно для приложения.
Я предпочитаю перечисления, поскольку они обеспечивают раннее связывание значений в коде, чтобы исключения не вызывались отсутствующими значениями
Также полезно, если вы можете использовать генерацию кода, которая может ввести ассоциации целочисленных столбцов с типом перечисления, так что в бизнес-логике вам нужно иметь дело только с легко запоминающимися значениями перечисления.
Считайте это формой документации.
Если вы уже задокументировали константы перечисления правильно в коде, который использует дБ, действительно ли вам нужен дублирующий набор документации (для использования и обслуживания)?