Re: Any reason not to have logic in the db?
From: Stephane Faroult <sfaroult_at_roughsea.com>
Date: Tue, 12 Jun 2012 14:22:24 +0200
Message-ID: <4FD73480.6050904_at_roughsea.com>
For those who wouldn't have already read Toon Koppelaars's excellent take on the question, here is the link:
http://thehelsinkideclaration.blogspot.fr/2009/03/helsinki-declaration-observation-1.html If I may venture an opinion the argument of making the application database-independent is mostly bogus. Even at the SQL level, it's rare you have two products that give the same name to otherwise identical functions (with special credits to T-SQL, which shortens length() and expands substr()); all products have interesting, unique, extensions that can be quite useful (Oracle has tons of analytical functions that most other products lack, but other products also have interesting features that sometimes allow for an elegant way to solve a problem); ignoring them and writing something clumsy for "portability" is an exercise in sado-masochism. . I have seen some applications migrating from one database to another database; but in most cases it has been a major migration effort (whether the code was stored inside the database or not) and usually a convenient opportunity to review the application in depth.
When the database is the only input and output for a process, the only reason why I could imagine not wanting to write the process as a stored procedure would be to share the load between server and client(s) - assuming that there is load besides database operations.
Date: Tue, 12 Jun 2012 14:22:24 +0200
Message-ID: <4FD73480.6050904_at_roughsea.com>
For those who wouldn't have already read Toon Koppelaars's excellent take on the question, here is the link:
http://thehelsinkideclaration.blogspot.fr/2009/03/helsinki-declaration-observation-1.html If I may venture an opinion the argument of making the application database-independent is mostly bogus. Even at the SQL level, it's rare you have two products that give the same name to otherwise identical functions (with special credits to T-SQL, which shortens length() and expands substr()); all products have interesting, unique, extensions that can be quite useful (Oracle has tons of analytical functions that most other products lack, but other products also have interesting features that sometimes allow for an elegant way to solve a problem); ignoring them and writing something clumsy for "portability" is an exercise in sado-masochism. . I have seen some applications migrating from one database to another database; but in most cases it has been a major migration effort (whether the code was stored inside the database or not) and usually a convenient opportunity to review the application in depth.
When the database is the only input and output for a process, the only reason why I could imagine not wanting to write the process as a stored procedure would be to share the load between server and client(s) - assuming that there is load besides database operations.
-- Stephane Faroult RoughSea Ltd <http://www.roughsea.com> Konagora <http://www.konagora.com> RoughSea Channel on Youtube <http://www.youtube.com/user/roughsealtd> On 06/12/2012 01:43 PM, Octavian Rasnita wrote:Received on Tue Jun 12 2012 - 07:22:24 CDT
> From: "Paul Linehan"<linehanp_at_tcd.ie>
> Subject: Any reason not to have logic in the db?
>
>
>> Hi all,
>>
>>
>> Apart from my various meanderings as a DBA and
>> programmer, I am also in College by night and thus
>> want to get at the fundamentals of CS and databases.
>>
>> I don't profess to being an expert (I wish!), but I believe
>> that I've grasped at least the rudiments of my field, i.e.
>> databases and how they should be used.
>>
>> I've read loads (apart from my studies) of blogs and
>> Oracle (which as we all know, has its flaws) books.
>>
>> What I want to know is: Is there any reason whatsoever
>> to have logic outside the database that could potentially
>> be kept there - notably CHECKs, CONSTRAINTs,
>> TRIGGERs, containing possibly complex PL/SQL - i.e.,
>> it's sort of a question about App-tiers vs. DB.
>>
>> My own opinion (to put my cards on the table) is that
>> "logic" should be stored as far down the stack as possible
>> (DB, first, then app-server...&c).
>>
>> Anyone know of any counter-examples?
>
> 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