> 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 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
 12/23/2002 01:34 PM
 Please respond to ORACLE-L

 
        To:     Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
        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:
   1. Are your developers/management enamored with the concept of
object, or
is this just your own curiosity?
   2. 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.
[EMAIL PROTECTED] 


-----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: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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: Stefan Jahnke
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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: 
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to