>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
toput things.
If a project may end up with tens of application servers connected to a single database, then you should let most of
thework on the application side.
But to discharge the database, you also have to keep transactions as short as possible. So if some logic process
requiresmany back and forth within a single transaction, then it may make sense to implement it on the DB side; most
developpersI'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
whydevelopers don't care for the SQL side. Testing should include some monitoring of the DB activity, which often
happensway too late.
I try since years to convince my colleagues, that application code doesn't matter ;-) What counts are the data and how
theyare 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,
mayhelp move some minds
best regards,
Marc Mamin
