Re: What do Oracle professionals think of Fabian Pascal?

Paul and others ,

Lets examine an example of Oracle extensions to SQL and commercially expedient solutions for problems .

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).

So what do Oracle hope to achieve (other than performance) by exposing an implementation detail from the physical data model through the logical data model ?

In general to provide an even more convenient way to update or delete a single row than having to specify match conditions for all key columns in the WHERE clause and specifically to facilitate a method for updating absolutely identical rows (duplicates) .

eg consider a table with 2 identical rows which could arise because SQL does not insist a table has a key (which is an RM (relational model) requirement) . How can you update or delete 1 of those rows ?

UPDATE table_name SET col1=val1 WHERE ..... AND ROWNUM =1 UPDATE table_name SET col1=val1 WHERE ROWID = &VAR / WHERE CURRENT OF CURSOR Now here is the key point , is it better to provide extensions to allow processing of individual duplicated rows or would it have been better to outlaw duplicate rows by insisting each table has a key ?

The features which provide row level processing just do not incentivise people to elevate their thinking to consider sets of data rather than individual objects and this is holding data management back .

2) Constraint Support

Did you know that a constraint is any condition you can think of which must evaluate to true (in binary logic) in order for an update of the database to be plausible ? (in SQL's inconsistent 3 valued logic it must evaluate to NOT FALSE ) .

Is there anyone who has contributed to this thread who would not like Oracle to support more constraints than it does and thinks Oracle constraint support is adequate as it stands ?

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 ) .
eg ii) to ensure that the key values of 3 tables are disjoint - ie a key value is unique accross more than 1 table eg iii) an exclusion constraint to match the FK inclusion constraint eg to ensure that a key value does not exist in another table .

To my knowledge the only enhancement to constraints Oracle has made since 7.3 is deferring checking to commit time . I welcome this expedient solution but through studying recognise that it is problematic and have become aware that it is not even the only way DBMS products could address the problem .

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 ?

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 . Received on Sun Sep 25 2005 - 10:03:48 CDT