Thank you for your useful input. In my case, all of the lookup table controls are populated on form being instantiated. And since each control is instantiated separately, it would be the same number of trips to the server - regardless if I keep the data in one table or in many tables. My main consideration for breaking one table into many is 1)easier to have RI 2)not "aggravating" DBA with bad design.


>I think the first factor to be considered is how many trips to the server will be required to retrieve lookup data.
>
>If you know you need 25 different lookup tables every time you bring up your app, or a particular form, ideally you'll retrieve everything on one trip. Personally, I keep the tables granular but grab all the data with one sproc to fill 25 business objects.
>
>Having all of it in one table makes writing the sproc easier, you just have to parse out the result.
>
>But think in terms of reducing server trips. It's called "chunky".
>
>
>>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