just_vladimir,

Если справочник в БД, то константы в коде идут лесом. Всё просто же.

just_vladimirДак вот что то пока плохо себе представляю как их лесом то отправить, вот есть код, в котором switch/case или просто какая-нибудь конструкция на базе if/else, что мне с ней делать?
Железная линейка + HashMap<Value, Action>

just_vladimirНу в самом тупом случае, мне нужно с каждой записью (строчке в таблице, элементе в графе, да где угодно) сопоставить некоторую иконку, которая определяется типом элемента, типы элемента это записи в таблице справочнике, какие будут предложения на этот счет?
запись_в_таблице.svg

just_vladimirНу так себе решение, а если для одного типа мне нужен один перечень пунктов контекстного меню, а для другого типа другой перечень пунктов контекстного меню?
По-хорошему вы заводите класс, на каждую запись в базе. Внутри класса есть ключ, который однозначно ассоциируется с записью в БД. Ключ, очевидно, нужно использовать натуральный, а не синтетический. Во время запуска находите все такие классы и складываете в Map.
Для тех кто использует if/else и switch с такими словарями и нужна железная линейка. Для каждой новой записи в БД, вам придется искать все такие условия по коду и добавлять в них блоки. Вместо того чтобы написать 1 новый класс с логикой нового элемента.

just_vladimirПро то, что он в идеале должен быть натуральным это согласен, тогда вероятность проблемы становится гораздо ниже, но, к сожалению, не всегда так получается сделать.
А что там переживать? При инициализации, собрали Map, сравнили с БД и дальше по вашей бизнес-логие: fault, warning или email админу.

just_vladimirок, спасибо, вариант понял, валидация на старте приложения.
Ну, тут важно понимать откуда наполняется справочник и где он первичен, а где вторичен. Например, если БД его особо не использует, вы можете наполнять справочник из кода при той же инициализации. И тогда в коде можно иметь полноценный Enum.
Но не зная требований сложно сказать какое решение подходит именно в вашей ситуации.