Re: Perl or SQL ?

[cbrandtbuffalo]

In response to your performance question, you're right to at least question where you should do your heavy lifting in this case. Databases are often faster than perl when it comes to queries and fetching data, but there are times when perl will be faster because of what you are doing. One example is the 'in' statement in Oracle--Oracle can have performance issues with that and sometimes perl is faster. Your example of a union is another case.

If you have the time and resources, the best way to get a feel for the performance of each is to try it. Set up a best and worst case scenario for the number of joins that would be needed. Given the info you provided, set up a query with 1 join and one with 8 joins. Then run them in both scenarios. This is the best way to get data you can trust and feel confident with when you make your final decision.

Want a guess? The database will be faster with 1 union, perl faster with 8. The break-even will be somewhere in the middle. If this is truly the case, you need to make a call based on how often users will request each end of the spectrum.

I too am a little puzzled by the 'views on the fly' solution. I'm no Sybase expert, but it doesn't feel right to me. I think you're likely to lose a bunch of your performance in the creation of the views.

Good luck.

[Anonymous Monk]

Thanks for the answer. There's one bit of information I missed off the supplied sql which is kinda important...
The select includes a date range e.g.


select * from sysaudits_01 where suid in (1,2,3,4,5) and eventtime > '
+$suppliedtime'
union
.
.

This therefore doesn't lend itself to using a stored proc solution since due to the variable timestamp input the sql is ever changing.
Thanks to you for your answer and the others who have shared there wisdom. As always there are many ways to skin a cat !