sumlin,

Perhaps you have implemented these things in the field in different ways than what I've seen. Said performance draining bloat and data dictionary issues are the results that I personally have witnessed.

In the extreme case, the application was a very large securities data warehouse which used a centralized lookup table. The warehouse was five years old and countless hands had been involved in adding various types of entities to the table. No one had bothered to delete deprecated entities (and there were HUNDREDS), developers had named entities based on a variety of schemes both real and imagined, and no one was left from the time of the original creation of the table. As a result, confusion ruled the day. Do we use the 'CTY' tag to find a city, or the 'CITY' tag? Both have cities! Join performance was horrible. The nightly build also included parallel processes that both needed to write different types of data to the table, causing disc IO issues.

Solved all issues by spending a lot of time sorting through the data, figuring out what belonged where, and breaking everything into individual lookup tables with properly defined constraints. Join performance shot way up (no more needless sifting through unrelated data), I was able to seperate the tables to different discs to optimize the nightly build, and was able to eliminate a lot of confusion. Yes, had they bothered to maintain documentation the latter wouldn't have happened, but honestly, how many shops have you been to that had even slightly up-to-date documentation (again, years AFTER the initial build phase)?

As for your situation with the view on each table, that seems a bit unwarranted. What are these views doing, other than selecting straight from the lookup tables?