>What might I cover that I haven't mentioned? >What are the usual objections to server-side code and how can they be met? >When *are* they justified and what should the criteria be to put code in Postgres? Any other thoughts? Hi, For my point of view, scalability considerations and possible performance gains are the key arguments to decide where to put things. If a project may end up with tens of application servers connected to a single database, then you should let most of the work on the application side. But to discharge the database, you also have to keep transactions as short as possible. So if some logic process requires many back and forth within a single transaction, then it may make sense to implement it on the DB side; most developpers I'm working with are resistent to this aspect. ORM layers are usefull, but nasty as they transform the database into a blackbox. I guess this can be a major reason why developers don't care for the SQL side. Testing should include some monitoring of the DB activity, which often happens way too late. I try since years to convince my colleagues, that application code doesn't matter ;-) What counts are the data and how they are arranged within the DB. Therefore they should put more focus on them, rather then think in OOM. That book is a great idea. A collection of bad code example and the SQL equivalents, strengthend with runtimes figures, may help move some minds best regards, Marc Mamin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
