Re: choices regarding where to place code - in the database or middle tier

From: Noons (wizofoz2k_at_yahoo.com.au)
Date: 01/21/04 

Date: 21 Jan 2004 00:03:32 -0800

danielroy10junk@hotmail.com (Daniel Roy) wrote in message news:<3722db.0401191316.646fd135@posting.google.com>...

> to SAP). My personal experience with the issue which interests you is
> that as much as possible should be stored in the database.

Hmmm, from the pure performance point of view that is usually
the case. But more needs to be said about that. If someone moves
a Java component into the database and that Java component
decides to retrieve the data to populate an internal object and
continues to apply methods to the object to ensure for example
referential integrity, the problem will still be there. It doesn't
just matter where the code is: the problem is also with the bad
object-relational mapping. Moving the code to the db is not
gonna solve that one.

The techniques for efficient storage and manipulation of data were
investigated ages ago and have been perfected over the last 30 years of
database technology. There is NOTHING that Java can add to that or
the OO model can improve on that subject. However, the OO-design
proponents insist and persist on ignoring the entire edifice of IT
already existant and do things their own way.
The result is a monumental impedance mismatch with no solution until
more rsponsible people are put in charge of these OO-based projects.

> Siebel, by
> some twisted reasoning about compatibility of code on various
> databases (it runs on Oracle, SQL Server and DB2), decided to keep
> almost all the code (including referential integrity!) in the middle
> tier.

There is worse. I know of one that decided to create its own
indexing structures and keep them inside a table as a BLOB.
So that they'd remain portable and "efficient"...

> As a result, on ALL the projects I've been a part of, we have
> had data issues. The worst part is for the foreign keys which are not
> valid.

I'm surprised you only got data issues. You'd also have appaling
performance on any significant volume of data. That seems to
be the constant on all these products with an internal design
decided by group hug...

> objects/columns which don't exist anymore, ...). Also, performance is
> always better from inside the database, from what I've seen so far.

By a very large factor. Orders of magnitude better in fact if the
object-relational mapping is properly done.

> This is logical since there is less network traffic when everything is
> done from Oracle.

Caching could prevent that, but like someone else pointed out
the problem is with cache synchronization. A BIG one. Oracle has
a thing called cache-fusion that is supposed to solve that problem. But
it didn't catch on that much with the 3rd-party brigade.

IMHO, business-rules code should reside in the middle tier. That is
by far the most scalable solution. But ANY code that deals with data
and its storage mechanism MUST reside on the db. How to make the two
talk? That is the province of object-relational mapping design and
database design.
The rules for those have been established long ago, people just insist
on taking 1 week Java courses and believe this replaces proper training and
experience.
Most unfortunate.

Cheers
Nuno Souto
wizofoz2k@yahoo.com.au

Relevant Pages

  • Re: choices regarding where to place code - in the database or middle tier
    ... > that as much as possible should be stored in the database. ... from the pure performance point of view that is usually ... a Java component into the database and that Java component ... object-relational mapping is properly done. ...
    (comp.lang.java.databases)
  • Re: choices regarding where to place code - in the database or middle tier
    ... > that as much as possible should be stored in the database. ... from the pure performance point of view that is usually ... a Java component into the database and that Java component ... object-relational mapping is properly done. ...
    (comp.lang.java.programmer)
  • Re: choices regarding where to place code - in the database or middle tier
    ... > that as much as possible should be stored in the database. ... from the pure performance point of view that is usually ... a Java component into the database and that Java component ... object-relational mapping is properly done. ...
    (comp.lang.java.programmer)
  • RFC: new DBI wrapper DBIx::Flexible
    ... The main goal is ease of writing a simple database app. ... schema is created/changed as you add data - when developing an application you ... This package is meant to be somewhere between a full object-relational mapping ... schema in advance) and a dbi wrapper (which usually just saves writing sql by ...
    (perl.dbi.users)