Re: how to test a string for a valid date in sql
Date: Mon, 14 Dec 2009 09:14:37 -0800 (PST)
Message-ID: <37d039f5-839c-43d4-9968-722021aea5aa_at_e4g2000prn.googlegroups.com>
On Dec 13, 6:50 am, "Gerard H. Pille" <g..._at_skynet.be> wrote:
> Robert Klemme wrote:
> >> A table lookup will never beat a couple of lines of sql "logic".
>
> > When it comes to using words like "never" and "always" I am very
> > cautious. Next someone might turn up with an example where a table
> > lookup beats what you call "SQL logic" by an order of magnitude.
Well, you can get scalability problems which can arise, for example, Jonathan shows how at some data volume sorts can spill to disk and slow things down: http://jonathanlewis.wordpress.com/2009/09/07/analytic-agony/ Of course, doing a four-pass operation when Oracle should have done an optimal sort was eventually considered a bug, but before it was considered a bug, it would quite possibly be a candidate for table lookup coding to beat it.
I think this might generalize to a postulate that at "normal" memory settings, there's going to be some situation where there's enough complexity in a join aggregation forces multipath sorts that could be avoided by table lookup coding. "Normal" is hard to define since part of tuning is changing memory settings, so I won't go there, but I hope I'm getting across that scaling volume and complexity can lead to all "sorts" of examples.
None of this is to say analytics don't rock and roll, just that it is important to delineate any limitations. One limitation is that it is putting old 3GL style ordered control break logic into a nonprocedural language, possibly obscuring other implicit limitations.
>
> > Cheers
>
> > robert
>
> I'd love that, to get to know the feeling to be wrong for once.
On usenet, you don't need to be wrong to get the feeling! :-)
>
> ;-)
>
> But you are right to be cautious.
jg
-- _at_home.com is bogus. Why don't we ever see SP2-00750?Received on Mon Dec 14 2009 - 11:14:37 CST