Re: How do you like this SQL?
Date: Fri, 14 Dec 2012 18:38:06 +0000 (UTC)
Message-ID: <pan.2012.12.14.18.38.06_at_gmail.com>
On Fri, 14 Dec 2012 09:30:33 -0800, joel garry wrote:
> Well, if the model is messed up, isn't it kind of useless to blame the
> developer?
Well, you have to blame someone and blaming the developer is always a good choice. Survival of the fittest developers will eventually raise the quality of the applications that they develop. Thus, by blaming the developer you are fulfilling an important social function and making the applications better. The fittest developers will be able to deflect the blame and put it squarely on somebody else, which makes things even more interesting, as long as people remember that the DBA is never at fault.
> I run into this kind of stuff all the time, since I do
> maintenance and customization on MRP/EPR, written in a SQL generator.
> When I have to fix data, I have the choice of using SQL or the more
> abstracted 4GL, which can generate even worse SQL. So my first thought
> on seeing the OP was "shoot, that is way too much like what I've been
> working on." In my case, the model isn't really messed up, it merely
> suffers from necessary over-generalization to accommodate various
> business practices (I have to add rows with line numbers one greater
> than the max, based on a subset of the attributes). When I'm under time
> and correctness constraints to fix data more than coding a production
> quality program, I have no problem writing bizzarro code, slow-by-slow
> generated in a shell script from a report, or 3GL style 4GL code. You
> can't argue the data should be captured with correct constraints,
> because the requirements and definitions are changing. Sometimes this
> code gets productionized when people realize it's useful on an ongoing
> basis. So it goes.
>
> I'll often use SQL just because it makes me think in sets and I think
> that's the right way, but when that gets too squirrelly, whatever the
> problem calls for that I'm most comfortable with.
>
> I have not seen any proof that analytics will be faster, aside from
> obvious situations where it avoids multiple passes through the data.
There can be no proof that analytic functions will always be faster. I don't even believe that to be the case. One should benchmark. If there were no benchmarks and the table really is, as John has put it, a really, really big table, then the application developer definitely is at fault.
-- Mladen Gogala The Oracle Whisperer http://mgogala.byethost5.comReceived on Fri Dec 14 2012 - 19:38:06 CET