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

From: Hans Forbrich <fuzzy.graybeard_at_gmail.com>
Date: Tue, 12 Jun 2012 08:27:37 -0600
Message-ID: <4FD751D9.6050806_at_gmail.com>



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.

/Hans

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 --
> http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jun 12 2012 - 09:27:37 CDT

Original text of this message