"Billy Verreynne" <vslabs_at_onwe.co.za> wrote in message
news:1a75df45.0309050440.4e992a8e_at_posting.google.com...
> "Manfred Pruntsch" <manfred.pruntsch_at_ifcos.com> wrote
>
> > I'm looking for a persistance layer to bridge a java application with
oracle
> > in a object relational way. I didn't find anything on oracle's website.
So I
> > asking for experiences and recommendations for stable applications.
Links to
> > reviews, articles treating this stuff are also welcome.
>
> Well, within Oracle a persistant object basically is the physical row
> in a table - or a relationship that describes (joins) or or more rows.
>
> Which can be described with a UDT with properties, constructors and
> member methods - in Oracle.
>
> > We use Oracle 9.2/Java 1.4.
> > Some requirements:
> > - Transaction
>
> Standard and best practise Oracle transaction methods apply. Don't
> treat that differently because of an OO design.
>
> > - Object identity
>
> Explain. (duplicating refenrential integrity and relationship in an OO
> class hierachy when it is *already* done in Oracle is just plain
> stupid)
>
> > - Relative independent from business layer
>
> That is achievable even without OO. It all depends on how you select
> to implement it.
>
> - do you provide a PL/SQL API to read, write & change table rows?
> (instead of a manual SQL SELECT, an API call is used to retrieve
> the data - business logic resides at caller's side)
>
> - do you provide a business PL/SQL API to perform business
> processing on Oracle tables and rows?
> (business logic, or big portions of it, now resides in
> PL/SQL)
>
> - do you wrap Oracle tables with UDT and OO interfaces?
> (and as above, do you do this at basic data access level
> or at business access level?)
>
> I personally see no advantage in having the business layer outside
> Oracle. The only exception being an ISV and developing for a variety
> of db platforms.
>
> What really gets me swinging my lead pipe is that the *fundemental*
> concept of an object is encapsulation.. and yet the Java dudes want to
> create the object outside Oracle instead of making it *part* of the
> data INSIDE Oracle. And yeah it can be done - no Java required.
>
> And maybe that is exactly the problem. It just rubs the Java dudes the
> wrong way that it can be done better and faster and more secure
> without using The Holy Language.
>
> > - Handling a bigger amount of objects
>
> In Oracle I can create a cursor that holds any number of rows. I can
> make it a reference cursor (PL/SQL function call) and pass the handle
> to the client so it can go trolling through a billion rows. (good luck
> with that - and don't call me for snapshot too old and rollback size
> problems)
>
> However, the first question is WHY. Doing something like that only
> displays a severe lack of ignorance about db processing.
>
> The second question is also WHY. Why do this when the data (i.e.
> objects) ALREADY persist in Oracle as rows? Why construct them again
> in the business tier? (answer: piss poor architecture choice, bad OO
> class design and poor OO implementation)
>
> > - Stable for production environment
>
> That depends on how savvy you put into your Oracle config. Treat it
> like it's MS Access and you're in for a rude awakening.
>
> > - Good understandable API...
>
> You define the API. How good and understable that is, is directly
> related to your design and coding of said API.
>
> If I seem a bit crass Manfred, it is because I have seen Oracle being
> treated like a silly persistant object repository where none of
> Oracle's features and advantages are needed, resulting in poor
> performance, wasting money and frustrating the hell out of the DBA.
> And dealing with a pissed off DBA is sure to ruin your day.. ;-)
>
> --
> Billy
My thoughts exactly. My why was to know why not to get a list of
requirements. I've been building applications that make extensive use of
rdbmss for decades and simple, tried and true, direct methods are best. Too
much indirection and faddish techniques get you into trouble. For Java guys
make everything stored procedures in the database. Then the database is
encapsulated and anything else is too hard for a lot of them to deal with.
Jim
Received on Fri Sep 05 2003 - 09:15:09 CDT
