Re: Any reason not to have logic in the db?
From: Remigiusz Sokolowski <remigiusz.sokolowski_at_nordea.com>
Date: Tue, 12 Jun 2012 14:51:58 +0200
Message-ID: <4FD73B6E.9000801_at_nordea.com>
W dniu 12.06.2012 14:22, Stephane Faroult pisze:
> 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:51:58 +0200
Message-ID: <4FD73B6E.9000801_at_nordea.com>
W dniu 12.06.2012 14:22, Stephane Faroult pisze:
> 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.
>
>
But I could point at least one reason to do so (ie. put the logic to app servers instead of db) - the economic one. Let's take MySQL db (which lacks in features) and some JBoss app servers where the cost of support is significantly lower then in case of Oracle db and put on several "cheap" x86 machines. Of course I must agree that not always this is a viable solution, but for some startups or businesses where one doesn't need to support its product with some market reputation, etc. it is really good choice
-- Pole na kazi ---------------------------------------------------------------------- Remigiusz Sokolowski <remigiusz.sokolowski_at_nordea.com> pos : Senior DBA at DIiUSI addr : Nordea Bank Polska SA, Luzycka 6A Street, 81-537 Gdynia, Poland phone : +48 58 667 17 43 mobile: +48 602 42 42 77 Nordea Bank Polska S.A. z siedziba w Gdyni, ul. Kielecka 2, 81-303 Gdynia, wpisana do Rejestru Przedsiebiorców Krajowego Rejestru Sadowego pod numerem: 0000021828, dla której dokumentacje przechowuje Sad Rejonowy Gdansk - Pólnoc w Gdansku, VIII Wydzial Gospodarczy Krajowego Rejestru Sadowego, o kapitale zakladowym i wplaconym w wysokosci: 277.493.500,00 zlotych, NIP: 586-000-78-20, REGON: 190024711-- http://www.freelists.org/webpage/oracle-lReceived on Tue Jun 12 2012 - 07:51:58 CDT