Re: What do Oracle professionals think of Fabian Pascal?

striebs wrote:
> 1) Extensions : eg ROWID and ROWNUM pseudo-columns
>
> Rowid is a transient identifier of a row of a base table which as we
> know happens to correspond to the address of the physical
> representation of the row (storage).

You are correct about ROWIDs, exposing them to the user achieves nothing.

ROWNUM is a hack that predated analytical SQL extensions, and some of these extensions do make sence for an end user. Otherwise, how do you express the query

"list all the employees with their salary ranks"

?

> 2) Constraint Support

> Eg i) a declarative constraint to ensure each invoice must have at
> least 1 line item (which can only be simulated with a constraint on a
> materialised view which outer joins invoice_header and
> invoice_line_item ) .

Why "simulated"? This is pretty legitimate way to enforce complex constraints (aka ANSI standard assertions). The method can be traced back to the 80s when database recearch has been pretty much alive; check out the papers on materialized view refresh.

Oracle materialized view support might have a lot to be desired, but that's a different story.

> 7.3 is about 13 years old , zoom forward to 2018 - how confident are
> you that Oracle will have significantly enhanced it's constraint
> support by then ?

Constraint enhancements is not a top priority nowadays. Wake up: the bleading edge of research and development is XML, Fusion, whatever.

> 3) Data-types and domain support
>
> In Oracle User defined datatypes are difficult to define and use .
>
> Wouldn't you like to be able to do rudimentary things simply like
> define a datatype of country_code based on a built-in datatype such as
> varchar2(2) and then add a column to a table as follows ADD
> (nationality TYPE country_code NOT NULL) and be able to deal with it AS
> CONVENIENTLY as if it has been defined as VARCHAR2(2) ?
>
> To answer you original question I think that Fabian Pascal , Chris Date
> , Hugh Darwen , David Mc Goveran are the first authors we need to read
> in order to understand our subject .

This is true to some extent, but may I suggest that there were a lot more people who defined and shaped the database world as it exists today. Received on Mon Sep 26 2005 - 17:43:23 CDT