>I'll probably get fired so saying this, but my CIO has laid down the law saying we can no longer use a summary table to get data about our members and, instead, we need to go to the "Master Data" tables.
>
>We have almost 200,000 members and we have a lot of date sensitive layered data about the member in many different tables. Typically, we want to get the most recent layer data item like their current address - not their address five years ago.
>
>We have a VFP table and a VFP process that summarizes some 150 fields worth of data into a summary table for the members. The process takes over an hour to run.
>
>So, instead of one stop shopping using the summary table the CIO says we have to go to each history data table and pull the max address or whatever.
>
>I don't see the advantage of this approach other than it will slow things down and make the code more complex.
>
>Opinions?

Another vote with Hugh and Bill. A view is the right way to go pulling data on the fly.. I assume when you query this data it is not usually for all 200k members. Properly indexed you should be able to pull your data easily with views. ( and if you move your data to SQL server it will even be faster and easier to do )

I also doubt if you always are interested in all 150 columns. Sounds like a number of parameterized views - dynamic parameters at that - would make life easier and network traffic better.