Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Guidelines for using Oracle 9i Object Relational Features

Re: Guidelines for using Oracle 9i Object Relational Features

From: FC <flavio_at_tin.it>
Date: Sun, 12 Jan 2003 11:41:07 GMT
Message-ID: <nvcU9.24880$AA2.1217599@news2.tin.it>


"S.T.Arun" <arun.srinivas_at_wipro.com> wrote in message news:85161575.0301080619.310475d_at_posting.google.com...
> Hi,
>
> I would like to know if there is anyone who has used Oracle's Object
> relational Features in a live project. If so, I would like to have
> some guidelines on do's and don'ts, the problem faced, solutions to
> them (if they exist!!). Most important of all the performance
> comparision between using ORDBMS and RDBMS.
>
> We are to propose the usage of Oracle 9i Database with OO
> implementation using Pro*C/C++ and Java. Any help in this regard
> would be great.
>
> Thanks in advance.
>
> Regards
> Arun

I've been using user defined object types containing varrays and bfiles successfully in 2 projects with Oracle 8.1.7 and I only had minor problems with the PL/SQL parser, but I always managed to find alternative ways to rewrite them.
Query syntax can easily become a nightmare when objects are involved, if you got lost once in a CAST-MULTISET dispute, you know what I mean. I am talking server side, I always enforced developers to use stored procedures whenever they wanted to talk with the db, never let them go too far with their home grown SQL statements. I always talked with them in terms of function's or procedure's parameters rather than in terms of table columns, save when they were developing stuff like statistical screens where they had just to wrap columns in nice colors. So, developers are not hard-coding object relational stuff in their client applications, they merely call functions or procedures. I didn't embark myself into programming "methods" and "object views", because I didn't need them, so I can't tell. Distributing well the workload among developers gives several advantages. First of all developers don't need weeks of training on Oracle and can focus on the client's development. If the task of interfacing to Oracle is left to people who already know how to do it, you save money. Second, I have something to do myself, instead of watching in a deep state of boredom what others are doing.
Last but not least, the privilege of being always on time with the project's schedule which makes the customer happy. It's very likely that plain tables work faster, but when I developed my prototype I spent some time trying to simulate a working environment 10 times worse than the real one and the response time was great or better than expected anyway.
The choice of objects was primarily due to the intrinsic nature of the problem, that can be easily represented by object classes (machines feeding boxes with piles of newspapers) and it proved to be the right one apparently.
It's handy to have everything stored in an object when you have to move it to some other place or delete it altogether. On the other hand, it can be very tricky to migrate existing data when your customer (as he always does) will come to you and says: "it would be nice to have this extra piece of information here!" and you find out that you need to change the structure of the object. Also consider the additional complexity of SQL loader scripts if you are to load external data. I think you must evaluate carefully how many components might require relational constraints and how you are going to access these objects. In my case most of the object's attributes are values that don't require complex logic, there are counters, weights, flags, just one integrity constraint, so they are not complex.

The system is now working since 9 months, never stopped once (crossing my fingers!!!) and distributes nearly a million copies of newspapers daily.

Cheers,
Flavio Received on Sun Jan 12 2003 - 05:41:07 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US