Re: Challenging SQL Query Problem. Can you solve it?

From: Jay Dee <ais01479_at_aeneas.net>
Date: Fri, 23 Dec 2005 00:31:23 GMT
Message-ID: <vzHqf.219931$tD4.188728_at_tornado.ohiordc.rr.com>


Karen Hill wrote:
> X-No-Archive:yes
>
> HansF wrote:
>

>>On Thu, 22 Dec 2005 14:48:10 -0800, Karen Hill wrote:
>>
>>
>>>DA Morgan wrote:
>>>
>>>
>>>>There is no such thing as an Oracle database without it.
>>>
>>>In the interest of portability, I have to be mindful that I don't use
>>>an Oracle only function.
>>>
>>
>>Please read Chapter 1 of Tom Kyte's "Expert Oracle Database Architecture:
>>9i and 10g Programming Techniques and Solutions" for a good discussion on
>>the reality of your database indeependence requirement.
>>
>>Your desire to stay database independent is simply going to cause your
>>customers to increase their cost.  Database independence means not taking
>>advantage of the vendor's capability, which in turn means more CPU
>>cycles, and THAT means more CPU and therefore more licenses to do the
>>same job.

>
>
> Not unless you use PostgreSQL. No license costs there. For those that
> are starting out, PostgreSQL is a good alternative before moving onto
> Oracle when they get bigger. Remember not everyone has the luxury of
> having unlimited Fortune 500 funds to aquire the best DBMS like oracle.
>
>
>>What you really want is intelligent use of those features.
>>

>
>
> Hans, Tom Kyte is an Oracle writer. He has a vested interest to say
> that. I would think throwing developer time to rewrite something is a
> *lot* more expensive than throwing in an extra CPU. Maintaning bug
> free SQL code for multiple vendors seems like big trouble. Remember,
> SQL is supposed to be platform independent unlike what we saw pre SQL.
>
> I would like to hear others opinions on this.
>
"Throwing in an extra CPU" is not a trivial task, even when the incremental license cost is zero.

Maintaining bug-free SQL code for even one vendor is expensive.

Maintaining SQL code that can be moved from one DB platform to another is difficult -- but not as difficult as designing data structures that facilitate moving the data from one DB platform to another.

The only data that can make the leap are those that can be represented as integers or constant-width character columns. (Numerics declared as decimal have a pretty good chance, but the results of applying even the "standard" arithmetic operators to those may differ.)

Staying within the bounds of ANSI or FIPS "minimum" capabilities is an arduous task.

For that matter, designing and developing a system that can survive a same-vendor release upgrade is difficult. (There's a reason that Oracle provides "compatibility modes" and Tom Kyte gets a chance to write a new book when the next release hits the market.) Received on Fri Dec 23 2005 - 01:31:23 CET

Original text of this message