Обычно выбор определяется количеством вариантов значения. Если их максимум десяток - разумнее использовать ENUM, иначе всё-таки таблицу-словарь.

Cyrax_02Самый железный фактор ( Фактор 1 ), от которого необходимо отталкиваться - могут ли пользователи добавлять новые состояния. Если могут, то однозначно таблица-справочник.В этом случае первые два варианта просто неприменимы, и выбирать собсно не из чего.

Cyrax_02в клиентском приложении придётся создавать перечисление, ключи (индексы) которых должны совпадать с ключами записей в таблице-справочнике. Попахивает дублированием данных
Я, признаться, не могу въехать, о чём речь ведётся. Такое впечатление, что Вы говорите о том, чтобы хардкодить набор вариантов состояний на клиентской стороне. Ибо нет никакой проблемы на старте приложения запросить содержимое словаря и соотв. образом сформировать источник данных необходимого контрола или получить идентификатор варианта по его мнемонике.
При обмене же со сторонними программными комплексами обмен предпочтительно вести именно в мнемонике, особенно если не выполняется онлайновая синхронизация словарей между комплексами. К тому же такой вариант позволяет сформировать вменяемо-читаемую таблицу соответствий (и при необходимости использовать прослойку-конвертор), а в условиях запрета ввода несуществующих в словаре значений опасность опечатки практически нулевая.

Cyrax_02авторнет никакой проблемы на старте приложения запросить содержимое словаря
Если возможные значения будут представлены строковыми константами или типом ENUM, то как будет выглядеть запрос возможных значений ?



Cyrax_02К примеру, некоторая сущность в некотором поле может иметь 5 значений. Для двух из них имеет место свой (индивидуальный) алгоритм обработки, для остальных - общий алгоритм обработки:



Наверное, всё-таки какой-нить там CASE или SWITCH... в пыхах не силён.

Cyrax_02В этом где и в каком виде целесообразно хранить возможные значения ?
И что из себя будут представлять значение1 , значение2 , ... - строковую мнемонику или значение перечисления ?

Учитывая, что данные о сущностях (включая эти самые значения) будут передаваться в другую программную систему, которая также должна уметь различать эти значения.
Подобные ветвления должны организовываться на стороне принимающей данные системы, и там должна быть таблица выбора метода обработки - соответствия между значением поля и неким внутренним для системы индексом (т.е. в коде выше значениеХ - это ни разу не то, что передано из внешней системы, а соответствие переданного значения внутреннему коду метода обработки) используемого для этого значения метода. А как выполняется идентификация значения в этой таблице - по мнемонике или по её индексу - в общем, неважно, проверка-то на равенство. С учётом того, что вероятность изменения мнемоники выше, наверное, предпочтителен внутренний согласованный индекс (из таблицы соответствия подсистемы импорта данных).

Cyrax_02 , ты сам задал вопрос о сферическом коне, так что нефиг возмущаться.
На практике у разработчика есть хренова гора требований, органичений и прочего хлама. И выбираемый подход определит именно она, а не абстрактное соображение, что какой-то вариант кошернее.