NYCPHP Meetup

NYPHP.org

[nycphp-talk] application logic in stored procedures

Hans Zaunere hans at nyphp.org
Fri Nov 7 10:21:11 EST 2003



felix zaslavskiy wrote:

> I am just trying to get an understaning if its a good way to go. I
> have not implemented a full blown web based business application
> before but I have been doing a bit of looking around the net on the
> topic. It seems people say for anything that is not trivial and
> involves some tricky business rules go with full featured dbms, in my
> case that would be postgresql. For fast search/lookup stuff like many
> web stuff mysql may be faster. Then choosing mysql the option of
> stored procedures is no longer available. What I am afraid of is if I
> use mysql alot of my php code would be start looking like this start
> trabsaction->query->process->query->proces->query->end transaction.
> If this is the case why not just put most of this mess in a stored
> procedure?

That's a perfectly valid line of thought, and is exactly why MySQL will be getting stored procedures in the next major release.  MySQL/PGSQL are difference animals, at least for the moment, and excel in different areas.  You might even consider using both for a very large project.  That said, there is business logic and then there is business logic.  Pick the database(s) that are correct for the project, but don't pick something because of buzzwords (like "business logic goes in stored procedures") and be sure to define your tasks well.

> I dont like this turn into another pg vs mysql thread. I like to hear
> how people made decisions on wheather they needed stored procedures
> on basis of their project requirements.

It's a tough call.  I still have not been romanced by PGSQL, but certainly see it's value.  As a side note, we'll be having a great presentation on PGSQL from one of the core developers in Jan or Feb.

H




More information about the talk mailing list