Bob,

Make him a view of the data, with all the lookup fields "looked up" and let hiim query the view.

Explain that there are serious problems with not normalizing the data store, but you can normalize the data and provide him with something that is easy for him to query at the same time.


>Erik, I Agree
>
>In a similar vein though, I have a boss who wishes to run his own adhoc queries and reports, but would never be able to do the joins necessary to accomplish this, thus he requires the data not to be normalized :-)
>
>Bob
>
>
>>>Another reason for breaking normalization is maintain integrity in your reporting. For example, let's say you have item descriptions that can change. In a lineitems table, you might elect to carry the description that existed when the lineitem was created. This way, when your item descriptions change, your past reports won't change.
>
>>Not to nit-pick, but this isn't really denormalization. If the item description for a lineitem needs to be recorded at the time of the invoice, and that description can later change independently of the invoice description, the current description and the historical description are two distinctly different pieces of information, and are not duplicated.