> 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
matures.
> 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
results
> 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
independent.
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
since
> you are carting ALL global variables into the symbol space of each call to
GetData.
> Running under Apache with register_global_vars that meant 158 variables
even
> without any GET or POST variables. However the new reference count
implementation
> of variables in php4 may minimise the impact of this. With any luck, it
won't
> actually make a copy of any of your global variables in memory! I was
pleasantly
> 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
158).
> I guess the choice between your approach and the more conventional
approaches
> of in-line selects, per-select function call, or encapsulation as a data
object
> is simply about maintainability. Personally I always prefer more lines of
boring
> 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.
Fred
--
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]
