On 25/07/13 07:57, Luca Ferrari wrote:
On Thu, Jul 25, 2013 at 2:57 AM, Some Developer
<someukdeveloper@xxxxxxxxx> wrote:
The added advantage of removing load from the app servers so they can
actually deal with serving the app is a bonus.
Uhm...I don't know what application you are developing, but I don't
buy your explaination.
While it is true that you are moving CPU cycles from the application
server to the database server, you will probably end with the
application server waiting for the database to acknowledge (and
therefore not serving requests) and usually the computation is not
that heavy for an online transaction (it would be better to do it as
batch if that is really heavy). Therefore this is not an advantage for
me.
Again, the only reason to use database facilities (like stored
procedures) is to arm the database so that even a different
application/connection/user will interact following as much business
rules as possible.
You are forgetting that you can execute a query asynchronously using
libpq therefore the app server can continue serving requests whilst the
database server chugs away on its work. You just poll the server every
now and again to see if the work has finished.
Moreover, please also note that one reason developers tend to avoid
database facilities is that they are using some kind of
stack/orm/automagical library that does not allow the usage of deep
features in sake of portability.
I'm not planning on creating a complex application in the database in its
own right, just augmenting what is already available with a few time savers
and (a couple of) speed optimisations for commonly carried out tasks.
I don't understand the "time saving" argument: you have to implement
the logic either in the application or the database, so let's say the
time of the implementation is the same. The only advantage of the
database is the code reuse. But take into account that there are
drawbacks, like debugging that is not always so simple.
Luca
Time saving was probably the wrong expression to use. The application
has parts written in different languages running on different servers.
It saves time to have the main work done using stored procedures since
they can be shared between the different systems regardless of the
language that particular service was written or the operating system
that it is running on.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
