Re: Counting events and getting top 5 matches

I'm a strong supporter of the view that when you can have the DBMS do the work, you must.

I'm not so sure that's always the case. There can be a real tradeoff between performance and maintainability there. I've seen some of the hairy twenty-page stored procedures people write when they're trying to do something in SQL that is fundamentally better suited to a general-purpose high-level language and would be less than a screenful of clean, easy-to-read Perl.

Certainly, there are times when it's better to have the DBMS do the work...

We're working on a six-year set of freely redistributable Vacation Bible School materials.

Comment on Re: Counting events and getting top 5 matches

Replies are listed 'Best First'.
Re^2: Counting events and getting top 5 matches by BrowserUk (Patriarch) on Sep 17, 2008 at 15:14 UTC
Get the best of both worlds. Use PL/Perl to write your SP in a GP that you're familiar with. Then run it where the data is and only tranfer the results. Rather than transferring all the data to where perl, is only to throw some large percentage of it away. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^2: Counting events and getting top 5 matches by psini (Deacon) on Sep 17, 2008 at 12:48 UTC
Agree. My point is that it is useless (== bad) doing a "generic" SELECT and then filtering or aggregating the data client side. Transferring business logic into stored procedures is another matter: I tend to use SP only to guarantee data integrity, where referential integrity rules are not enough. Rule One: "Do not act incautiously when confronting a little bald wrinkly smiling man."	[reply]