Re: Any reason not to have logic in the db?
From: Niall Litchfield <niall.litchfield_at_gmail.com>
Date: Tue, 12 Jun 2012 13:57:04 +0100
Message-ID: <CABe10sZsR54NAHBLfaAfkqoXVvauTOz3obojJL8vafWmp2zHtg_at_mail.gmail.com>
On Tue, Jun 12, 2012 at 12:43 PM, Octavian Rasnita <orasnita_at_gmail.com>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.
>
>
I assume by "change the database" you mean "move from Oracle to MySQL" or similar, i.e change the platform. Frankly this is a mad argument. It's logically equivalent to "its not a good idea to keep the business logic in the application because it would be very hard to change the programming language which will be used by your application in the future and your app won't be flexible" Incidentally, my experience of this industry suggests to me that data and databases live far longer than the application that they were originally written for and acquire interfaces which process data that the original application never envisaged and often has no control over (for example batch loads to/from other systems).
Date: Tue, 12 Jun 2012 13:57:04 +0100
Message-ID: <CABe10sZsR54NAHBLfaAfkqoXVvauTOz3obojJL8vafWmp2zHtg_at_mail.gmail.com>
On Tue, Jun 12, 2012 at 12:43 PM, Octavian Rasnita <orasnita_at_gmail.com>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.
>
>
I assume by "change the database" you mean "move from Oracle to MySQL" or similar, i.e change the platform. Frankly this is a mad argument. It's logically equivalent to "its not a good idea to keep the business logic in the application because it would be very hard to change the programming language which will be used by your application in the future and your app won't be flexible" Incidentally, my experience of this industry suggests to me that data and databases live far longer than the application that they were originally written for and acquire interfaces which process data that the original application never envisaged and often has no control over (for example batch loads to/from other systems).
I certainly don't think that all application code should reside in the DB Tier, I am however of the opinion that far more should than does (at least in the Oracle world, .Net and MSSQL developers are much more used to seeing the db as a feature rich tier). Toon's Helsinki Declaration series of blog posts which Stephane has already pointed out are well worth reading here.
> 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
>
>
>
-- Niall Litchfield Oracle DBA http://www.orawin.info -- http://www.freelists.org/webpage/oracle-lReceived on Tue Jun 12 2012 - 07:57:04 CDT