> Well you have an interestingly different approach!

Glad I could entertain you!

> Personally I kind of like either having the SQL statements in-line with
the rest
> of the code or functions that retrieve data for that particular query e.g.
> function get_students($class) {....

The problem with using your approach (in my sitation) is that I have quite a
few Selects that are rather long and used in several places throughout the
project.  I prefer to maintain the Selects in a single place so that I know
they are always uniform (ie do not contain errors) and so that it is easier
to make a change to the Select statement itself.  This is particularly
important in this project because my client's tech guy is a moron and
continues to request changes to the underlying database as the project

> 1. You could still solve your problem of having to worry when the constant
> definitions are included by setting global variables instead of constants
> and then doing an explicit eval-uation at their time of use e.g.

Good idea.  Done.  Thanks.

> 2. I notice you return a pointer to the results set rather than the
> themselves.  This means you still have to have mysql_fetch_... outside
> of GetData.  Why not return an array of the result rows instead?
> i.e. add to GetData
> while ($rows[] = mysql_fetch_array($result));
> mysql_free_result($result);
> return ($rows);
> This has the advantage of letting the rest of your code remain database

I had considered that approach, and certainly prefer it from a
maintainability standpoint, but it seems to me that performance can become
an issue since I would have potentially large result sets in memory rather
than just one row at a time.  This particular client will have less than 30
users for the application and memory will most likely not be a problem.
However, I am positioning the project in the marketplace for schools with
hundreds of users and memory could indeed become a problem.

> 4. You should be aware that you approach may have performance implications
> you are carting ALL global variables into the symbol space of each call to
> Running under Apache with register_global_vars that meant 158 variables
> without any GET or POST variables.  However the new reference count
> of variables in php4 may minimise the impact of this. With any luck, it
> actually make a copy of any of your global variables in memory! I was
> surprised at how fast an extract($GLOBALS) ran, (7ms for me).

Well noted, I have replaced the extract($Globals) with global assignments
for the entire list of possible variables (which is considerably less than

> I guess the choice between your approach and the more conventional
> of in-line selects, per-select function call, or encapsulation as a data
> is simply about maintainability.  Personally I always prefer more lines of
> but simple code to clever structures which may be obtuse to the poor guy
who ends up
> maintaining my code.

My approach has certainly evolved over the years and I am sure it will
continue to do so.  In addition, my approach depends a lot on the particular
project I am developing.  One thing is certain though, the thing that
excites me about programming is the ability to devise clever and abstract
ways to accomplish a task.  I tend to offset the obtuse nature of my code
with a plethora of inline comments, just in case a maintainer (or I) has a
difficult time following the logic down the road.


PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to