<<
I agree with you in principal except I like to use VIEWS instead of temporary tables. I am sure that there may be instances where you could only do something with a temporary table but do't discount the use of VIEWS since you can have VIEWS of VIEWS.
If you need a table you could always PROJECT it from the view.
In the years that I have been a member of this list it has been my impression that VIEWS are an underutilized feature of RBase.
>>I agree with you in principal except I like to use VIEWS instead of temporary tables. I am sure that there may be instances where you could only do something with a temporary table but do't discount the use of VIEWS since you can have VIEWS of VIEWS.
If you need a table you could always PROJECT it from the view.
In the years that I have been a member of this list it has been my impression that VIEWS are an underutilized feature of RBase.
My original statement was a bit of an oversimplification.
My first approach is to use a permanent view in the database if possible. If that fails, I'll try a temporary view, or series of temporary views. If that doesn't give me the results I need, or has performance problems, I'll go to a temporary table solution -- often starting the calculations by projecting from one or more views to get the initial data.
The biggest advantage that sending the data to a temporary table has is in performance. Firstly, I get more control over performance by decomposing the computation into a number of steps -- in effect, I can get some manual control over optimization. Secondly, I can quickly restrict my dataset to the records I need. Finally, you have to pay the view computation costs every time you hit the view -- with a temporary table you only pay once. So I'm able to let the user enter a complex selection, test it by counting the records or browsing them, and then to select several different dispositions for the data (a detail report, a summary report, a set of PDF files and an Excel spreadsheet) without having to pay the computation costs again.
The important issue I wanted to stress for Dan is getting the complex calculations out of the report expressions and instead presenting the report writer with a dataset that looks pretty much like what you want the report to look like.
--
Larry
