amachanic,

1) This technique is still being used many years after it's creation, and being used by many other developers that may at first balk at the concept due to purity sake, but realize that for clarity and ease of use it is a good idea. In fact, I contend the value of the technique gets better the longer the application is around, and especially with applications that are continually changing.

2) Why do you assume that there is no well maintained data dictionary? If, as required by some business requirements, they want to see a separate entity per domain, I'll just give them a view (e.g. v_CustomerType).

3) And what makes you think that there's performance problems? I once had this debate in an architectural design meeting when building a table that had about 25 lookup fields. It was assumed that by joining to the Look table 25 times was going to be slower than joining to 25 different tables. That assumption proved wrong. It turned out it was actually faster (not by much) to use the Look concept. That was a project almost 5 yrs ago, so I don't have the performance data still.

4) You mention damage it eventually causes? I'm curious as to what kind of damage that this technique causes that you have to be called in to repair.

5) The time is not necessarily saved on table creation, that's obviously an easy task. The time isn't necessarily saved on the creation of INSERT/UPDATE/DELETE procedures for each of those tables or creation of views for those tables, although the addition of these objects does start to make the list of objects in your database get much longer. The time saved is on the application side. Instead of having to create a class for each table, or functions for each data manipulation process, you only do it once. No matter how many fields, domains, values you add to the database. Yes, you could try to create a generic class that basically took an object name and dynamically determined which procs to call, but that becomes a very fragile piece of code. (I know, I've tried that way too)

For example, I currently am interfacing with a DB2 database developed by another development team completely, although I have been tasked with reporting functionality. They developed the database with separate lookup tables...all 200 of them. There have actually been problems with their lookup tables (see a question I just posed under a different thread http://www.sqlservercentral.com/Forum/topic.asp?TOPIC_ID=18853&FORUM_ID=23&CAT_ID=2&Topic_Title=How+would+you+do+this%3F&Forum_Title=General) that would have been avoided using my technique. This database has so many lookup tables that just scrolling the table list becomes a pain in the rear. Realize that they have a view for each table and 3 procs for each table. That's 600 procs!!! What did they gain? IMHO, not very much if anything. Did they add complexity and bloat (your term) to a database structure and application architecture? I think so.

I think that this technique holds more appeal if you have to do both database architecture and application programming. My .02

David