Oooohhh, boy, did this one ever bite me in the butt...
Ok, the OTLT is a bad idea in general, because of what everyone else has said. There are a number of guises this succubus of a db design feature will don to seduce the developer/dba.
First, is the "common schema". That is, you have a bunch of different tables, but they all have exactly the same structure. And I do mean exactly the same. For example, a pair of "cash pile" tables that's partially denomalized for performance reasons. Say, having a cash header table for summary (cash total, coin total, etc.). Then you have the cash denomination table that basically has a cash header field, denom field, and amount.
Let's also say you have maybe 15 different kinds of records that use a cash pile. So, the OTLT philosophy would say "put a type field in the header record and voila!, problem solved". One pair of tables that hold a "cash pile" entity.
Except, you've created a hotspot. Anything that needs info on cash amounts is going to be hitting those tables. Worse, those two tables are likely to be *huge*, millions of records in even a small company with a couple of years of data.
Second, unless you're VERY careful it would be extremely easy for error conditions to change the type field of records read/written and then you have a real mess on your hands.
The second guise is the one you've run into, a lot of different data going into a master lookup table. That's perhaps the easiest one to swat because there's no upside to it. At least in the cash pile example you can reuse the same code to read any type of cash pile. With the table you describe you lose that one "advantage".
Having said that, if the OTLT succubus does get its claws into the design, there's actually one guise that's fairly harmless, but it requires a huge amount of discipline to make it work. (read, extra work on the developer's part).
Create a pair of tables. The first (header) has 3 fields maximum. These are a primary key (probably an identity), the "lookup table name", ie the name of this "virtual table", and (optionally) a varchar(max) field for human readable notes that describe what the "virtual table" is for.
The second table contains 3 (possibly 4) fields as well, an identity to be the primary key (good for audit logging of changes, etc), the human name for combo boxes and lastly a varchar field (possibly max, but probably varchar(10) since this is a code which is supposed to short!) and (optionally) a varchar(max) field for human readable notes describing the entry. Optionally you can also include a byte field for numeric codes, but that's starting down a bad road...
Then, follow these rules about what type of "virtual tables" you're creating:
1) Data must be static, i.e. it doesn't change much and (hopefully) never deletes entries. States (in the US) are a good example of this.
2) Data should be no more than 10 entries (or so) in a given "table" (ie queries against the combobox entries should never be expensive).
3) Ideally, these "virtual tables" should be looked up once when the application starts running, so the cost is incurred when the user is more relaxed. This lessens server load while the application executes, as well.
Given the restrictions above I won't say OTLT (at least in the most benign guise) is a worthless idea, but it's certainly not the beguiling creature it makes itself out to be. :laugh: