Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Guidelines for using Oracle 9i Object Relational Features
"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