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.

Finally, take cascaded update and renaming columns. These are features I actively oppose. I regard it as a fundamental principle of data theory that the identity of a data object is persistent, inseparable, and immutable for 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 robust and more maintainable
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 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 - 09:48:35 CDT