Re: Any reason not to have logic in the db?
- From: Stephane Faroult <sfaroult@xxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Tue, 12 Jun 2012 14:22:24 +0200
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:
> From: "Paul Linehan"<linehanp@xxxxxx>
> 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
>
>
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
