Posted by: Clinek
Oracle applications, Oracle database administration
In recent months, Oracle has been bragging about its thirty years of innovation, beginning with its debut in 1977 as the “first SQL relational database management system. The time-line begins like this:
- 1977 – Software Development Laboratories, the precursor to Oracle, is founded by Larry Ellison, Bob Miner, and Ed Oates.
- 1978 – Oracle Version 1, written in assembly language, runs on PDP-11 under RSX, in 128K of memory.
- 1979 – Oracle Version 2, the first commercial SQL relational database management system, is released. The company changes its name to Relational Software Inc.
. . . and so on. At last month’s Collaborate show, Oracle’s “Dr. DBA” Ken Jacobs acknowledged Oracle’s debt to the relational model pioneer Ted Codd.
However, some commentators have always argued that the Oracle DBMS doesn’t really conform very well to the relational model or standard SQL at all. I recently came across an old — but still relevant — thread rant by “striebs” that outlined some Oracle violations:
- “ROWID and ROWNUM extensions: ROWID is a transient identifier of a row of a base table, which happens to correspond to the address of the physical representation of the row (storage). So what does Oracle hope to achieve (other than performance) by exposing an implementation detail from the physical data model through the logical data model? . . . 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 that 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.
- “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? . . . [Does anybody really] think that Oracle constraint support is adequate as it stands?
- “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 – like 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)?”
Don Burleson wrote an interesting article about how Oracle departs from the relational model, citing the debate about Codd and Date’s “omission of physical storage in their relational model.” He writes:
Oracle officially changed their data definition language (DDL) in the 1990′s to allow the Oracle DBA to physically sequence table rows (to improve runtime SQL performance) by allowing “create table as select” syntax to include the “order by” clause. Since then, Oracle has incorporated many physical storage features into their object-relational model, introducing cluster tables, the index-organized table (IOT), and the Oracle 10g sorted hash cluster table structure.
Of course, Don notes that the relational model says nothing about physical storage on purpose, since it is specifically designed to separate the logical from the physical.
Indeed, Date and his colleagues would call Oracle an “SQL DBMS,” not a relational DBMS. What do you think? Does Oracle deserve its reputation as a relational model innovator? Or was it never meant to be a “pure” RDBMS, but rather an object-relational DBMS?