Proper term for ie: creating an order_status lookup table with attributes to avoid coding against specific status values?

Question

Is there a proper term in data modeling to describe the following?

Given table [order] table with an [order_status] column, which when first conceived has 5 acceptable values, obviously having 5 different meanings and at least > 1 behavior (but not necessarily 5 different behaviors) from an application perspective.

One would typically determine the explicit differences (especially that drive application behavior) between the acceptable values and create a lookup table with explicit columns defined to declare this fact for eack lookup table. For example, one might have [is_valid], [is_outstanding], [is_onhold] columns. And subsequently, both sql and application code would act upon these attribute columns, rather than using hardcoded references to the acceptable [order_status] values themselves, ie:

-- get all active orders (using hardcoded values) select * from order where order_status in ('new', 'approved', 'on_hold', 'requires_confirmation')

So, is there a proper term to refer to this practice?

Update

Of course this is simple logical common sense application design that one learns via experience, but I am hoping there happens to be a proper formal term for the practice (preferably within the domain of data modeling) documented somewhere to which I can refer a relatively inexperienced but overconfident consultant over whom I have no direct authority.

Answer 1

So, is there a proper term to refer to this practice?

Application Design.

Seriously. This is just design of an application. There's no fancy-schmancy design pattern name for this. It's just plain-old design.

These "facts" are simply processing status codes and processing rules. The rules -- what to do -- is what application programming is all about. Binding application code to data via encoded status codes is so essential and fundamental it doesn't have a name. It's just a status code.

Theoretically, you're binding a Strategy object to each order. You only have five Singleton strategy objects, each a polymorphic subclass of an overall Strategy class definition.

Then, you're providing an object identifier (i.e., a numeric code) that you can dereference to locate the appropriate Strategy object.

Answer 2

When code flow is determined by (potentially) mutable data in a table somewhere I've always seen this in the literature as "data-driven code". State machines are classic examples, programs like file(1) which mostly work from the contents of /etc/magic are another.

If that doesn't please, I'd pillage terminology from the Prolog literature.