Re: How to determine database market share?

From: David Cressey <david.cressey_at_earthlink.net>
Date: Wed, 16 Nov 2005 09:26:47 GMT
Message-ID: <rXCef.9125$2y.3924_at_newsread2.news.atl.earthlink.net>


"hpuxrac" <johnbhurley_at_sbcglobal.net> wrote in message news:1131207612.773915.86300_at_z14g2000cwz.googlegroups.com...
> # Meanwhile most relational databases, particularly Oracle, become less
>
> # relational with each release. Codd defined relational as the extent
> to which
> # the user of the data (via DML) is isolated from the way the data is
> # physically stored. Some of these things are to improve performance
> (like
> # hints in Oracle) or to improve concurrency (WITH UR in DB2) but they
> are
> # decidedly not relational in nature.
>
> Um I guess I would agree (maybe somewhat) with only your first sentence
> above.
>
> Starting with the second sentence you are not exactly close.
>
> The relational model says nothing about physical storage.
>
> The relational model says nothing about hints in SQL statements.
>
> The relational model says nothing about concurrency.
>
> Each vendor has developed proprietary technology to improve the
> performance of their products agreed.
>
> But arguing that these parts of the technology stray from a relational
> model when the model doesn't say anything about them is not good logic.
>

In the abstract, you are correct. But your point misses the gist of the comment you replied to, IMO.

In order for the DML programmer to be in fact isolated from the product specific "enhancements" to the relational model, it has to be possible for the programmer to acheive satisfactory results without resorting to special tricks to tell the DBMS how to do its job. If the DML written by the programmer produces logically correct results, but fails to meet performance requirements, then the programmer will be forced to reprogram in order to get the desired result with the desired speed.

This undermines the value, in practice, of the original goal of isolating the programmer from the implementation details.

Take hints, for example. If the programmer is forced to use hints to get the optimizer to choose the fastest strategy among several, then the DML programmer is forced to spend time and mental effort thinking about HOW to access the data rather than WHAT data to access. The bang for the buck goes downward.

While this may be of little theoretical importance, it is of great practical importance.

Having said that, I don't think the products are getting "less relational" as time goes on with regard to such things as hints. Some 10 years ago, the Oracle optimizer was "rule based", choosing such things as the "driver table" by the order of appearance of tables in the FROM clause. That's, in effect, a subtle hint.

Since that time, Oracle has added the cost based optimizer, and many queries that formerly would have been executed by one strategy are now executed by a different (hopefully faster) strategy. I've been told that the Oracle CBO drew a lot of ideas from the Oracle Rdb optimizer, after Oracle bought DEC Rdb/VMS from DEC. Received on Wed Nov 16 2005 - 10:26:47 CET

Original text of this message