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

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 only heard of it being used one place, and the developers involved were converting to get away from it. I've thought of using it purely in PL/SQL, but as our DBA's won't let us install any Types for fear that we might use them in a table this is unlikely to happen.

Share and enjoy.

Answer 3

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.

Answer 4

I've used simple types with constructors and a few methods to wrap some functionality of interacting with an existing tcp server. I needed to pass x bytes (raw object) and receive back x bytes (clean object). I could have written some procedure that was particular to my task, but using object type allowed this to be a bit more generic for others. Nothing fancy, very basic OO stuff, create the raw object, populate a handful of its 100 or so properties, call its clean function, and assign the result to a new "clean" object. Anyone else who wanted to call the tcp server could follow the same basic steps, only populating whatever raw values with their data.

Still, in my experience I wouldn't say Oracle is object oriented, but rather has some basic functionality of objects. And as others said, companies don't buy Oracle for it OO capabilities. Don't get too caught up in it with Oracle imo.

Answer 5

It's not too uncommon to see them play a small role somewhere in your system. For example, if you're doing something with Oracle data cartridge. Some times when you need to do something really weird they are necessary.

It is uncommon to see them used extensively in a system. I've seen two different systems use a lot of objects and it was a disaster both times: difficult to use, very slow, and full of bugs.

"Simple" relational methods that use basic tables, rows, and columns are almost always good enough. Every programmer (and program) can understand these concepts, and they are powerful enough for almost any task. Yet you can spend many years trying to fully understand and optimize these methods. Object relational technology adds a huge amount of complexity on top of that for very little gain.

Answer 6

Many of the other answers have given good examples of where using objects does make sense; in general these are to handle some particular, perhaps complex, types of data. Oracle itself uses them for geospatial data.

What is not commonly done, except it would sadly appear in some college courses, is to use object-based tables instead of regular relational tables to hold regular data like employees and departments something like this:

create type emp_t as object (empno number, ename varchar2(10), ...);
create table emp of emp_t;

While these may be nice simple examples to teach the concepts, I fear they may lead to a new generation of database developers who think this approach is suitable, more modern and therefore better than "old-fashioned" relational tables. It emphatically is not.