Re: Reason(s) not to use a stored procedure
От | Ilan Volow |
---|---|
Тема | Re: Reason(s) not to use a stored procedure |
Дата | |
Msg-id | CB8D64CD-09E2-44EC-B737-025C214D8591@clarux.com обсуждение исходный текст |
Ответ на | Reason(s) not to use a stored procedure ("Mag Gam" <magawake@gmail.com>) |
Список | pgsql-novice |
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.
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:"
В списке pgsql-novice по дате отправления: