On Mon, Apr 14, 2008 at 11:34 AM, Rick Pasotto <rick@xxxxxxxx> wrote: > I have a function that includes a specific sql query that is used on > only one page on the site. Should that function be coded (1) in the page > itself, (2) in a separate file that only that page includes, or (3) in a > master file that contains all the functions used on the site and is > included on every page? Every time you include/require a file there is stat & compile stages that do add up over the execution of a script. It will do this on every single page request unless you have an opcode cache installed. Now with that said, it is better to organize your site than to build for optimum performance. Most sites will never reach the traffic necessary required to deal with tweaking every aspect for performance. You'll end up making it harder to maintain and see the flow of the site which costs you time. This is all subjective and there are many factors in it. But usually programmer time is more important than script execution time. Don't completely ignore it though that is just as bad. :) I organize all of my data access objects/functions very meticulously. In OOP sites I will create value objects & gateway classes for each table and their only job is to work on said data. For procedural sites I will create a file that contains functions that relate to a given table's data. In your case I would create a single include file somewhere such as /app_name/<table>/functions.php that would work against the table in question. The function prototype would be app_name_<table>_fetch_all(); or something along those lines that would return a data set of some sort. This way if you need to re-use it, extend it, find it, or get rid of it there's no guessing where it is. You can one off this case, but what about when you make other pages? What if they do have lots of functions that need to be organized? Then you've broken the consistency between where your functions are. Some might be in include files, others might be elsewhere. Sometimes it seems like overkill, but having a clear methodology for organization in the beginning is better than when you've got 30 files that play differently. Plus when you're really consistent like this you can easily view the real guts of your application and see how it works over time much easier without searching templates. Separation of code & design is a key for success! Just my two cents. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
