stenfordКак этого избежать и вообще возможно-ли?
Если оторваться от БД и подумать глобально, то способов избежать "хардкодинга вообще" при сохранении той же бизнес-логики не существует, существуют лишь способы заменить неудобный хардкодинг (например, единицу) более удобным (например, константой appApproved). Удобный хардкодинг имеет несколько отличительных особенностей: компилятор ловит синтаксические ошибки, лексема имеет легко читаемый вид, простые модификации легко осуществляются в небольшом количестве ясных по коду мест, идеально - в одном месте.

В БД универсальный способ, отвечающий этим требованиям - использовать хранимки наподобие SetApplicationApproved, то есть по сути закодировать константы в названиях ХП. Также можно использовать [updateable] view с полями типа status_approved, status_declined etc. Кроме того, конкретные СУБД могут иметь специфические способы решения той же задачи. Итого - решения в принципе есть, но не факт, что лучше, чем уместный "прямой" хардкодинг.

Например, в одной из своих разработок я поступил следующим образом: завёл пакет с константами (Oracle) и использовал их в серверном коде; в запросах же, приходящих с клиента, компонент запроса ловил фрагменты вида where status = &approved и подставлял туда распарсенное значение константы из пакета.

Но в любом случае, это лишний повод подумать о том, чтобы изменить бизнес-логику с целью отказа от хардкодинга, и вместо чётко заложенной модели смены статусов предусмотреть более универсальную конфигурацию.