В большинстве проектов есть какие-то данные, которые по существу статичны между выпусками и хорошо подходят для использования в качестве перечисления, например, статусы, типы транзакций, коды ошибок и т. Д. Для примера, я просто буду использовать обычное перечисление состояний:
public enum Status {
ACTIVE(10, "Active");
EXPIRED(11, "Expired");
/* other statuses... */
/* constructors, getters, etc. */
}
Я хотел бы знать, что делают другие с точки зрения настойчивости в отношении подобных данных. Я вижу несколько вариантов, у каждого из которых есть очевидные преимущества и недостатки:
- Сохраняйте возможные статусы в таблице статусов и храните все возможные объекты домена статуса в кэше для использования во всем приложении.
- Используйте только перечисление и не сохраняйте список доступных статусов, создавая священную войну согласованности данных между мной и моим администратором баз данных
- Сохраняйте статусы и поддерживайте перечисление в коде, но не связывайте их вместе, создавая дублированные данные
Я предпочитаю второй вариант, хотя мой администратор баз данных утверждает, что наши конечные пользователи могут захотеть получить доступ к необработанным данным для создания отчетов, и отказ от сохранения статусов приведет к неполной модели данных (контраргумент: это можно решить с помощью документации) .
Есть ли здесь соглашение, которое использует большинство людей? Каков опыт людей с каждым из них и есть ли другие альтернативы?
Изменить:
Поразмыслив над этим некоторое время, моя настоящая борьба за постоянство приходит с обработкой значений id, которые привязаны к статусам в базе данных. Эти значения будут вставлены как данные по умолчанию при установке приложения. На этом этапе у них будут идентификаторы, которые можно использовать в качестве внешних ключей в других таблицах. Я чувствую, что мой код должен знать об этих идентификаторах, чтобы я мог легко извлекать объекты состояния и назначать их другим объектам. Что мне с этим делать? Я мог бы добавить еще одно поле, например «код», чтобы искать информацию, или просто искать статусы по имени, что неприглядно.