How widely used are Oracle objects?

Question

I'm writing an assignment for a databases class, and we're required to migrate our existing relational schema to Oracle objects. This whole debacle has got me wondering, just how widely used are these things? The data model is wonky, the syntax is horrendous, and the object orientation is only about three quarters of the way implemented.

Does anyone actually use this?

Answer 1

For starters some standard Oracle functionality uses Types, for instance XMLDB and Spatial (which includes declaring columns of Nested Table data types).

Also, many PL/SQL developers use types all the time, for declaring PL/SQL collections or pipelined functions.

But I agree few places use Types extensively and build PL/SQL APIs out of them. There are several reasons for this.

1. Oracle has implemented Objects very slowly. Although they were introduced in version 8.0 it wasn't until 9.2 that they fully supported Inheritance, Polymorphism and user-defined constructors. Proper Object-Oriented Programming is impossible without those features. We didn't get SUPER() until version 11g. Even now there are features missing, most notably the private declarations in the TYPE BODY.
2. The syntax is often clunky or frustratingly obscure. The documentation doesn't help.
3. Most people working with Oracle tend to come from the relational/procedural school of programming. This means they tend not to understand OOP, or they fail to understand where it can be useful in database programming. Even when people do come up with a neat idea they find it hard or impossible to implement using Oracle's syntax.

That last point is the key one. We can learn new syntax, we can persuade Oracle to complete the feature set, but it is only worthwhile if we can come up with a use for Types. That means we need problems which can be solved using Inheritance and Polymorphism.

I have worked on one system which used types extensively. It was a data warehouse system, and the data loading sub-system was built out of Types. The underlying rationale was simple:

• we need to apply the same business rule template for every table we load, so the process is generic;
• every table has its own projection, so the SQL statements are unique for each one.

The Type implementation is clean: the generic process is defined in a Type; the implementation for each table is defined in a Type which inherits from that generic Type. The specific types can be generated from metadata. I presented on this topic at the UKOUG a few years ago, and I have written it up in more detail on my blog.Find out more.

By the way, Relational Theory includes the concept of Domains, which are user-defined data-types, including constraints, etc. No flavour of RDBMS actually supports Domains but Oracle's Type Implementation is definitely a step along the way.

Answer 2

I've never seen the benefit to it, mostly because when I last examined it, your object definitions were immutable once they were used by a table.

So if you had an Address object you used in a Customer table definition, you could never ever change the Address object definition without dropping the Customer table, or having to go through a very wonky conversion.

Objects are fine for data instantiation - like what an application does - but for data storage and set-based manipulation, well, I simply don't see the point.