NYCPHP Meetup

[Matt Juszczak]

> Whether it's in the database or in PHP, changing DBMS'es requires
> recoding some aspects of the project.  So put things where they best
> belong.  In the case you're proposing, a stored procedure is the right
> way to go.

Hi Dan,

Would the stored procedure route work best for all INSERT/UPDATE/DELETE 
actions of our code (and I'm working on creating views for SELECT's):

Such as:

createUser
createPost
createReply

Or is adding all of this logic into the database not a good idea?

As an FYI, I've done this 3-4 different ways in the past, where the DAL 
was in stored procedures, a "man in the middle" code approach, and inside 
shared libraries.  The problem with shared libraries right now is that 
there are multiple front ends, and even if they are in PHP, some are 
object oriented (MVC), and some are procedural.  Also, some of the front 
ends may be developed not in PHP, which would render those libraries 
useless.  The man in the middle approach is too big for us at this point. 
So that really only leaves stored procedures, but I always question 
putting all this logic in the database.

Thanks for your suggestions all!

-M