I've been in your situation. The logic here is "let's put EVERYTHING > into a single table, no lookups because joins are always bad". Then > something changes and I have to have downtime to update the table with the > changes. I'm preparing to do another one of these and it will take > approximately 2 hours of downtime, if all goes well. This is our OLTP and > it is rare that they actually retrieve these columns anyway so why use the > extra storage (which is far from cheap in our case). I vote for lookup > tables for columns like state, gender, codifiable columns rarely referenced, > etc. That being said, we do have a couple of columns in one table that are > codes that hit lookup tables that are referenced thousands of times a day > and they want the actual value, not the code. You need to understand what > the application is doing/new code will be doing before you can make an > informed decision about which is the best way to go. > -- > Sandy > Transzap, Inc. >