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
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
