> I'm using a postgres datbase for my PHP project, how do I make stored 
>procedures?  Or if no SPs then what would be recomendation for building 
>simple/reuseable "Put" and "Get" procedures for my data?

Well, if nothing else, PostgreSQL does support user-defined functions, going
'way back.

Technically not quite the same as a Stored Procedure, but should do what you

Of course, *WHY* you want to add such a ridiculous layer of overhead to your
code is beyond my comprehension, but that's another story... :-)

I once worked at a place where the head IT guy was convinced Stored
Procedures were the bomb.

Alas, he didn't tell me that until after I had coded the most of the ASP
application without them.

Meanwhile, deadlines were looming, and I wasn't migrating to Stored
Procedures, since I was furiously coding all the change requests (well,
okay, they were really "Features The Client Thought Up During Development
Because He Didn't Design Anything Beforehand" but they were called change
requests anyway.

So a new guy they hired was assigned the task of converting all my:

  $query = "select blah, blah, blah";

code into Stored Procedures.

Guess what?

*ONE* of the pages was a little faster.  The other hundred pages were just
as fast with $query = "select..."

Guess what else?

When we migrated from SQL 6.5 to SQL 7.x, all the Stored Procedures puked.

Guess what else?

Before the Stored Procedure conversion, it was trivial to Push from the Dev
box to the Production box.
After the conversion, it was a nightmare.  I ended up writing an Admin tool
to connect to both databases and compare the text of the Stored Procedure
source (buried in badly-designed Microsoft tables) between the Dev Server
and the Production Server.
Of course, in the first round *ALL* the procedures were different, since
Microsoft added/stripped altered the text of the Stored Procedures while
copying them from Dev to Server in the first place.

Guess what else?

There weren't enough queries "the same" that there was any real code re-use.
 I coded the application and the pages were designed properly in the first
place, so very seldom were two queries the same.  If they had been the same,
I would have put those two pages (features) into one.

Guess what else?

The new guy was in such a hurry, that in the few instances that two queries
*were* the same, he didn't bother to figure that out, so we ended up with
some Stored Procedures that were duplicates of others in everything except
their name.

Guess what else?

The @@INSERT_ID I was using worked differently inside a Stored Procedure, so
I wasted days tracking down a bug introduced by the Stored Procedures.

Guess what else?

When I went to edit the pages he had changed, I'd  have no idea what data
was coming back from the Stored Procedure, without reading way too many
lines of code.  With the $query = "select x, y, z" style, I knew exactly
what I was getting.

All in all, the company spent 4 weeks of this guys' life, 40 hours a week,
making the application less portable, less maintainable, and no faster.

And people wonder why I see little value in Stored Procedures.

Like Music?  http://l-i-e.com/artists.htm

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to