Oracle-L: RE: Object relational features and performance

From: <Jared.Still_at_radisys.com>
Date: Mon, 23 Dec 2002 14:53:54 -0800
Message-ID: <F001.00521824.20021223145354@fatcity.com>

> On the other hand, the business logic would be found partially in the > database and partially in the application server.

This sounds dangerous and non-performant/scalable.

Dangerous because data could easily be changed outside of the application and be unaffected by your carefully crafted business rules.

Non-performant/scalable because the data has to be outside the database to be verified by the business rules.

Jared

Stefan Jahnke <Stefan.Jahnke_at_bov.de>
Sent by: root_at_fatcity.com
12/23/2002 01:34 PM
Please respond to ORACLE-L

        To:     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
        cc: 
        Subject:        RE: Object relational features and performance

Dennis -

1+2;) The current project will be build with the "classic" relational data modell. On top of it sits a OR-Mapper (not a full-blown-vapor-ware-application server though ;) and the software will be
developed in java. The software development team is VERY experienced with object oriented software development (smalltalk, c++, java, you name it, they've done it).
I thought about going with objects (in the database that is) in the beginning but I didn't do it. The main reason for not going with that approach is the fact that things might get mixed up. For one thing, I don't
really get stuff like inheritance or interfaces, which are quite important.
On the other hand, the business logic would be found partially in the database and partially in the application server. So what would be left except for the encapsulation and abstraction ? Afterall, we used an abstraction layer which is the or-mapper.

Right now, I'm just curious if anybody has experience with object relational
oracle features and wether it might be a recommandable approach or not. In theory and on my little playground aka laptop it always looks good, but in real life, ... I don't know.

Regards,
Stefan

-----Original Message-----
To: Multiple recipients of list ORACLE-L Sent: 12/20/2002 5:39 PM

Stefan - I believe the general consensus had emerged that usually object features aren't worth the effort. Often there are few benefits, and if you
don't do it correctly you may see bad performance. Two questions:

Are your developers/management enamored with the concept of object, or is this just your own curiosity?
Is there something about your application that leads you to believe that it might derive significant benefit from the object features? For general business applications it is hard to beat the flexibility of the good old traditional relational data modeling. The lack of discussion may provide part of the answer to your question.

Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Friday, December 20, 2002 6:35 AM
To: Multiple recipients of list ORACLE-L

Hi everybody

I'm not quite sure wether this has been discussed in deep before, but I couldn't find anything satisfieing (hope the spelling is correct ;)) things
in the archive.
Anyway: Due to my lack of experience with any real life scenarios with Oracle's object relational features, I never tried to recommend the usage of
these and always kept to a "normal" relational approach. Does anybody have
any experience with Types / Nested Tables and the like in a (preferrably big) production system of any kind ? What's recommendable, where are the pitfalls ?

Any input deeply appreciated,
TIA, Stefan

--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: Stefan Jahnke
INET: Stefan.Jahnke_at_bov.de

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: DENNIS WILLIAMS
INET: DWILLIAMS_at_LIFETOUCH.COM

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: Stefan Jahnke
INET: Stefan.Jahnke_at_bov.de

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author:
INET: Jared.Still_at_radisys.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------