Re: Any reason not to have logic in the db?

  • From: Norman Dunbar <oracle@xxxxxxxxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Thu, 14 Jun 2012 07:07:32 +0100

On 12/06/12 15:27, Hans Forbrich wrote:
> ...
> If you want a commodity RDBMS, then chose a commodity RDBMS.  If you
> want an Enterprise RDBMS, then force it to yield up all of it's value.
> Oracle has 6 different RDBMS engines (Server, RDB, TimesTen, MySQL,
> InnoDB and Berkeley) and they make it easy to choose, and pay, according
> to your needs.  But the reality is that an application rarely switches
> engines once delivered.

I know only of one occasions where a "database agnostic" application 
switched backends. It ran on Oracle and was diabolically slow, parsed 
like mad, and did everything wrong. The DBA team I worked with at the 
time raised numerous service calls with the vendor.

The resulting outcome was that they didn't have any/much Oracle 
experience - being a SQL Server shop - so they advised that the only (!) 
way to fix the performance problems on Oracle was to use SQL Server instead.

We switched backends and surprise, it performed beautifully. The outcome 
further enhanced my cynicism about any vendor who claims to have created 
a "database agnostic" application - because it is extremely unlikely 
that they actually know how to use the features of one database, never 
mind all of the others!

>  ...

> ... Look at the ADF model, and
> tell me where the Business logic actually ends up (Ans: a tier within in
> the middle tier, and potentially spread across different technologies,
> with interesting complexity challenges).
It will probably all end in tiers! ;-)

> WHERE to put the Business Logic *should be* a response to the business
> requirements, including performance and skill set.
True, but is it not the case that most business logic is down to 
constraints of various kinds anyway? Granted not all of it, but most? It 
has been in my experience (maybe I need to "get out" more?) but the very 
fact that it is something the database does very well (in compiled C) 
means nothing to the vast majority of Java developers who always seem to 
reinvent the wheel for every application and treat the database as 
somewhere to "hibernate" their "objects". :-(


Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767

Other related posts: