The question is if this is a problem. In my experience, stored procedures can add performance and allow for code to run on a different server than the web server. But, if the expectations are to use other database platforms as well you may need to take that into consideration. You may end up writing stored procedures for each supported database, which adds extra work. But that is something that may be postponed after the initial release.
Makes sense. In all honesty, chances are most of our front ends will remain PHP, but the problem we're running into is that I'm not an object oriented programmer. So once I get done with the database work, systems work, etc., I want to help code, but avoid jumping right into the clean code base of our primary site. To help with that, I designed/developed our mobile site, which is a standalone code base split up cleanly (MVC-like), but not object oriented. I find myself duplicating a ton of logic, because none of it is in a DAL right now. Stored procedures would be great in this instance, but I wonder if it's for the wrong reason.
Furthermore, eventually we've thought of looking into something like MongoDB or Tokyo Tyrant depending on the traffic of the site, which could potentially complicate the issue if most of the logic is in the database. But as there will only be 20-30 stored procedures anyway, it wouldn't be too hard to re-write things at that point, as if we chose to go the Tokyo Tyrant/MongoDB route, we'd have to rewrite a lot of the schema and code anyway.
-Matt _______________________________________________ New York PHP Users Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/Show-Participation
