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

am Tue, dem 22.01.2008, um 8:49:39 -0500 mailte Mag Gam folgendes:
> 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?

Why not use procedural languages? He told more about the reasons?


With plain SQL you can't use control structures like loops, with
languages like plpgsql you can map your application logic into the
db-server. I can't see any reasons against such procedures. Maybe he
knows only old MySQL...

Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Tue, Jan 22, 2008 at 08:49:39AM -0500, 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?

putting application logic in the database is maybe what he does not like
about it. not beeing able to switch databases easily might be another.
but why not just ask him?

--
cu

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkeWC88ACgkQOO9i6TSuoN0ugwCgq+dF2HdO4i AG7FdSG7pnFT04
MtYAn3/JL5iShI/clbhl6JAt9VJ+b+GC
=okZL
-----END PGP SIGNATURE-----

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:"

magawake@gmail.com ("Mag Gam") writes:
> 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?

I can think of some reasons why NOT to do so...

- Code is often not terribly portable

- Sometimes the code isn't very visible

- In some ways, it's not very relational, and if the professor is a
"Darwen and Date" fan (somewhat unlikely), it can be argued that SPs
may look "less relational."

There are also some more or less compelling arguments in favour of the
use of stored procedures. I tend to think they outweigh the demerits.
--
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/advocacy.html
Roses are red
Violets are blue
Some poems rhyme
But this one doesn't.