IMHO, multiple lookups would be easier to set up for referential integrity. Recently we used the approach you described for lookup tables (one lookup for multi purpose) and it was a bit challenging to create queries and also you would not be able to set up relationship properly.

So, I would advise to use multiple small lookup tables. BTW, this is a common question and we may add it here

http://wiki.lessthandot.com/index.php/SQL_Server_Programming_Best_Practices (or better in Data Modeling Best Practices which doesn't exist yet).

You may also check http://forum.lessthandot.com/viewtopic.php?f=15&t=8562 and the thread referenced there.

>Hi,
>
>I don't know if this question was asked before (maybe even by me <g>) but I came across this issue again in converting from VFP data to SQL Server database.
>
>From the times when I was working in Clipper (and moved the app to VFP 6.0) I had a limit on number of handles could be used when opening tables, I have one table that is sort of a "container" for many "lookup" tables. The table structure is:
>
>TBL_ALIAS, C, 20
>ENTRY, C, 20
>DESCR, C, 40.
>
>By making different entries in TBL_ALIAS I can actually store many different (mostly lookup) tables in this "all-purpose" lookup table.
>
>When moving the app to SQL Server, creating another 20-25 small tables does not seem to be a problem. Hopefully it will not cause too much extra load on SQL Server (vs. having to deal with just one table).
>
>But my question is in general, what is a good practice - when creating a new application in SQL Server - using a separate table for each small lookup or combining them into one (as I did back in DOS times)?
>
>TIA