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

  • From: Hans Forbrich <fuzzy.graybeard@xxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Tue, 12 Jun 2012 08:27:37 -0600

The argument of staying database neutral on the possibility that we 
might change database engines in the future is roughly the same as "you 
are not allowed to use the electric windows or the radio in your new 
Mercedes because the next car might be a different make and might not 
have those features"

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.

It is difficult to security and performance in a middle tier [where 
those functions are] equivalent to that inherent in  the Oracle Server 
when properly configured and tuned.  And it *may* mean that you need to 
put in effort in creating and maintaining a duplicate to what already 
exists.  I usually chose not to pay for a feature twice - once in the 
RDBMS (to be ignored) and once in the application, where it increases 
complexity and cost.

RDBMS and Middle Tier are tools.  A professional understands the various 
tools at hand and chooses the correct tool for the job, or portion of 
job, at hand.

Business Logic entirely in the data tier makes sense in some cases.  In 
some cases it makes sense enitrely in the middle tier - assuming you can 
actually define a specific 'middle tier', because these days even that 
is fragmented, and pointing to a single box and saying 'that is the 
middle tier' is becoming more difficult.  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).

WHERE to put the Business Logic *should be* a response to the business 
requirements, including performance and skill set.


On 12/06/2012 5:43 AM, Octavian Rasnita wrote:
> It is OK to keep low-level logic like constraints in DB, because most 
> of the time if those constraints are not respected, the data may 
> become corrupted. But it is not a good idea to keep the business logic 
> in the database because it would be very hard to change the database 
> which will be used by your application in the future, and your app 
> won't be very flexible. Of course, if you don't think that you will 
> ever change the DB, and especially if you require the best possible 
> speed from your app, no matter how many million-hours of work it will 
> require, then you may also want to keep the logic in DB. Octavian -- 


Other related posts: