NYCPHP Meetup

NYPHP.org

[nycphp-talk] SPROCs in the MySQL/PostgreSQL + PHP crowd

David Wang dwang at udfi.biz
Wed Nov 10 16:48:03 EST 2010


I'll second this.  The problem i've always had in the past with sprocs is that it adds another layer of abstraction to the business logic and difficult to manage changes for.  I've always told my developers to move it out of the sprocs and into the code so we see what's going on and can manage changes in a code repository. 

The only time i've bit the bullet and moved logic into sprocs was when there was a mixed language environment.  Instead of duplicating logic, we put the logic in the database using sprocs so that both languages had access and logic didn't have to be duplicated.

-d

--
David Wang
Entrepreneur in Training
+1 (434) 298 4588 | dwang at udfi.biz |  www.udfi.biz | @daSn0wie  






On Nov 10, 2010, at 3:42 PM, Chris Snyder wrote:

> On Wed, Nov 10, 2010 at 3:31 PM, Jerry B. Altzman <jbaltz at altzman.com> wrote:
>> Hi all,
>> 
>> Just a question for those of you out there dealing with the F/OSS RDBMS's
>> out there:
>> 
>> How many of you are using stored procedures (SPROCs) with any great
>> regularity?
>> 
>> I know that in the commercial database world use of stored procedures is The
>> Way Things Are Pretty Much Done, but I've not seen it in my brief forays
>> through the bulk of PHP code I've examined (and needless to say, written).
>> Am I just out of it? Is it just not considered usual practice, or am I
>> blind?
>> 
>> In this I'm also including triggers and other stored functions, but not
>> parametrized queries (they're something different yet).
>> 
>> I'll be happy to summarize (and anonymize) to the list.
>> 
>> Thanks!
>> 
>> //jbaltz
>> --
> 
> I started in PHP/MySQL development before stored procedures were even
> an option, and learned to make due without them. Obviously a heretical
> approach, but when you know that the database is unlikely to be
> accessed by anything other than your php code, it makes sense to keep
> the logic in the application where it is easier to work with (and
> subject to version control).
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
> 
> http://www.nyphp.org/Show-Participation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20101110/6cedc579/attachment.html>


More information about the talk mailing list