Re: Persistance Layer wanted!

"Billy Verreynne" <vslabs_at_onwe.co.za> wrote in message news:1a75df45.0309050440.4e992a8e_at_posting.google.com...
> 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.

When talking about business object, those contain data and not much behaviour. There is little to nothing to encapsulte! The design of "business object" frequently ends up with a bunch of silly getters and setters.

> 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.

It's not necessarily the java, but just ignorance of data processing fundamentals. How many java dudes opened C.Date's "Intro into Databases"?

> 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)

But cursors are the last resort! Usually you query result set is small. No user is expected to scroll down to 1000th page of the query output and find some useful data there. The intermediate result, nevertheless, can be large, but it's up to query execution engine & optimizer to worry about that. (I wonder how many java folks ever heard about optimizer).

> However, the first question is WHY. Doing something like that only
> displays a severe lack of ignorance about db processing.

Aha! This makes my earlier comment redundant.

> 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)

Dismissing all this nonsence talk about "persistent layer abstraction" isolating "database implementation details" the business layer essentially becomes the Presentation. True, at presentation layer you have to use objects that you construct from your *data*. This is because nobody figured out yet how to describe the display artifacts in truly declarative language (aka SQL). The day one could program graphics in SQL (or better relational language) would render graphics objects obsolete as well.

> > - Good understandable API...
>
> You define the API. How good and understable that is, is directly
> related to your design and coding of said API.

API is stupid. There is only that much that you can do with API.

It is very common for object propellerheads to create "higher level" API to access database like this:

class PurchaseItem {

    static int[] getListOfIds( String criteria );     static PurchaseItem getItem( int id ); }

Then, it is easy for application developer to write a jsp page displaying a list of items, but impossible for performance analyst to do anything about poor performance.

Now, if API designer fall to this trap easily, how can O/R tool be smarter than him? How does it know what portion of object graph to prefetch? Lazy loading is a partial answer, of course, but it still hides the fact that lazy loading still [arbitrarily] partitiones a single logical query into multiple pieces.

> 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.. ;-)

Exellent comment. Received on Fri Sep 05 2003 - 13:16:14 CDT