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

danielroy10junk_at_hotmail.com (Daniel Roy) wrote in message news:<3722db.0401191316.646fd135_at_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_at_yahoo.com.au Received on Wed Jan 21 2004 - 02:03:32 CST