Re: Reason(s) not to use a stored procedure

IMHO, like most everything dealing with any kind of software
development, it's an engineering tradeoff.

When I write plpgsql stored procedures, I am trading:

- Easy portability between databases (to the extent that SQL is
portable between databases)

- Niceties like IDE's with useful IDE stuff like being able to
search through code (I had to write a custom application to do this
with plpgsql).

- Ease of SCM (I am having to write a custom application to do this
with plpgsql)

- Ease of debugging (via using a real debugger, that I have to do
absolutely no work at all to install and that I don't have to buy)

- Maintainability. I personally find maintaining large bunches of
plpgsql to be a major PITA. Code can easily get lost if you restore a
dump in the wrong way.

- A good, clean separation between application layers and storage
layers

for:

- Using loops and variables so I don't have to write and debug a
cluster**** of SQL spaghetti.

- Avoiding getting involved with introducing a separate middle-ware
server.

- Not having to change the Objective-C code for my rich-client,
recompile it, and redeploy it to get the change in behavior I want.
Updates are instantaneous and centralized.

Probably not the stuff that your professor mentioned, but it's what's
been my experience. Other experiences may vary.

On Jan 22, 2008, at 8:49 AM, Mag Gam wrote:

> I was in an academic meeting where a professor was preaching the
> reasons why not to use a stored procedure. He advised to always use
> SQL instead of a procedural language. Can someone please shed some
> light on this?
>
> THANKS
>

Ilan Volow
"Implicit code is inherently evil, and here's the reason why:"