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. 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
