I also agree with Melanie. As does my friend Joe. In his usual charming style from another list:

quote:

---

This is a common mistake that Newbies and idiots often make. They literally do not know what a table is. A table is a set of things of the same kind (as per 1NF and DKNF rules), so a nightmare that has sex codes, zip codes, UPC, ISBN, etc. in one place is BY DEFINITION not a table at all. Would you put octopuses and automobiles in the same table?

• No referential integrity can be enforced at the database level. Well, not without CHECK() constraints that are HUNDRED OF LINES OF PREDICATES.
• More code will be required to enforce the integrity at the application level. And there is no way to be sure that all the applications in the future will get it right!
• A query that needs only a few short look up tables that would fit into main storage will suck in the Super-table.
• Since some codes are numeric and some are alphabetic, you will be converting datatypes constantly from an insanely long string.
• Updating Super-table will lock it and prevent queries from running.
• Look ups done on two or more parameters (longitude and latitude, etc.) will require extra columns that the other scalara codes do not use at all, thus wasting space.
• The code is unreadable because instead of referring to, say, "sex_code" you have a general format of

  
  
     SELECT ...
  
       FROM Personnel
  
            SuperTable AS Sexcodes, 
  
            SuperTable AS Benefits, 
  
             ...
  
      WHERE Personnel.sex = Sexcodes.value
  
        AND Sexcodes.code_type = 'Sex'
  
        AND Personnel.benefit_code  = Benefits.value
  
        AND Benefits.code_type = 'Benefits'
  
        AND ...;

  One screw up and the query is garbage, but it will still run.

• If you want to use me as an authority, feel free to do so.

--CELKO--

---

--Jonathan