Deal with some old DBase application that don't (cannot) enforce referential integrity and you know why you should always use them. Even today there are modern samples of this and usually they just become inconsistent and getting good data out of them is a real pain.

Still I don't know why you don't stick to the subject of Referential integrity and get to using MUCK (or true-lookup-tables). They can become a real pain and they provide no benefit, except a good key to integrity problems. I've designed some lookup tables and the database had almost an equal number of lookup tables compared to other tables. In the end adding the lookup tables paid off because:

1. A slight addition was needed that the lookup table could provide, not much changes to meet the new requirement.
2. Adding some more bits and bytes with predefined condities to the lookup table made my filtering work much easier.

The first thing can be done with a MUCK table, the second one cannot. Besided, why complicate a design with such tables?

Even in OO you don't do what you do with MUCK tables, you only take benefit that the object has the same layout (so why not use the same class or definition(!)), but you don't put them in the same array, unless you are, IMHO, some kind of idiot.

It might confuse people that tables are NOT the same as classes, rather we should change SQL to:

CREATE DEFINITION Lookup (Id, Value)

CREATE TABLE CustomerStatus FOLLOWING Lookup

CREATE TABLE BatchStatus FOLLOWING Lookup

CREATE TABLE ... FOLLOWING Lookup

CREATE DEFINITION OrderLookup : Lookup (canceled bit)

CREATE TABLE OrderStatus FOLLOWING OrderLookup

Now we are going the correct way, view definition as class and table as array of a definition. But who's going to build it?