Re: Oracle #1? Then why are these still missing...

I see a different point. Every feature added to a product adds value, and also subtracts value, just as every book added to a library adds to and subtracts from the value of the library as a whole.

Most of the features requested in the original post are processing features that are central to a good programming language, but somewhat tangential to an RDBMS.

Take DIV, for example. No question about it, DIV is better than trunc(x/y). But the difference is so
slight that even two days of an Oracle engineer obliterate the value, IMO. If I'm doing trunc(x/y) a million
times in the context of processing a million rows, I care much more about the performance of the retrieval of the rows than I do about the performance of the truncation. If I'm doing trunc(x/y) a million times in the context of processing zero rows, then I'm using a processing environment, and not an RDBMS. In the processing environemnt, I expect a "real programming language", and I would be disappointed with the absence of a built in DIV.

Take TO_HEX, TO_BASE, and bitwise booleans as a second example. For the work I do on Oracle,
all this represents to me is a heavier reference manual, and slower access to the description of the features I use. In short, to me, it's just so much excess baggage. It's up to the Oracle company to decide where the trade-off lies between satisfying users like me, and satisying users like Paul.

[Quoted] Finally, take cascaded update and renaming columns. These are features I actively oppose. I regard it as a fundamental principle of data theory that [Quoted] the identity of a data object is persistent, inseparable, and immutable for [Quoted] the life of the object. In the case of columns, it means they don't change names. In the case of rows, it means they don't change primary key values.

I find that systems built in conformace to this principle are generally more [Quoted] robust and more maintainable
[Quoted] than systems that disregard this principle. So I would regard adding a column rename feature and a cascaded delete feature as a step in the wrong direction for an RDBMS. Again. it's up to the Oracle company to figure out [Quoted] who they are going to satisfy.

Regards,

    David Cressey mailto:david_at_dcressey.com

Gary O'Keefe wrote in message <37a04d1d.15481795_at_news.hydro.co.uk>...

>You are missing the point. These are the sort of atomic operations
>that can be quickly and robustly added to the interface. Their
>omission was a serious oversight, but can be corrected in (at the
>most) a couple of programmer-days. To people who need to perform this
>sort of calculation the performance increase would be incredible. It's
>not just business-weenies that use Oracle products (although they are
>the ones that pay for them ;), technical people need to be able to
>address the problem space they are presented with in terms they
>understand, and if the interface requires them to have to go round the
>houses for a solution to what they perceive to be a glaring, but
>frustratingly easy to correct, omission then confidence in the product
>will fall.
Received on Thu Jul 29 1999 - 16:48:35 CEST