NYCPHP Meetup

[Matt Juszczak]

> 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