Balancing speed against OO design - optimization issues with PHP/MySQL

[Jeffrey Silverman]

Hi all, a request for opinions, please.

I am designing a smallish application to manage members of several
committees of a particula Organization. The structure of the system is as
follows:
theOrganization
contains Committees
which in turn contain People

So theOrganization object is a list of Committee objects which are
themselves groups of People objects.

Now, to get the data out of the MySQL database, it is probably more
efficient to do as few SQL selects as possible. Efficient from a speed
point of view. However, from a coding/OO-style point of view, it makes
more sense to have each People object be defined as *one* person -- but
that would mean that each has data for only one person and that would mean
a separate SELECT statement for each People object created. (Assuming that
there is a SQL SELECT in the constructor of each People object or
something similar to that).

Traditionally (i.e. non-OO), to code this, I would do as few SQL calls as
possible. But I can't see how to do that from an OO point of view.

For example, does it make sense to put all the people data into an array
outside of the People class and use this list to set up the class
constructor? (It doesn't make sense to me)

Or, for example, does it make sense to have the People class just be a
list of *everyone* in the people table? (This too does not make sense to
me)

On the other hand, what is the performance impact if I *do* make each
People class instance be only *one* person?

Allright, I hope this makes some sense. Thanks (in advance) for the advice!

--
Jeffrey D. Silverman | jeffrey AT jhu DOT edu
Johns Hopkins University | Baltimore, MD
Website | http://www.wse.jhu.edu/newtnotes/

[Nikolai Chuvakhin]

"Jeffrey Silverman" <je*****@jhu.edu> wrote in message
news:<pa****************************@jhu.edu>...

I am designing a smallish application to manage members of several
committees of a particula Organization.
Notably missing from your description is the proposed functionality
of your software. In other words, you want suggestions as to HOW
to design the software without explaining WHAT this software has to
do.
The structure of the system is as follows:
theOrganization
contains Committees
which in turn contain People

So theOrganization object is a list of Committee objects which are
themselves groups of People objects.
Why even bother with 'theOrganization' and 'Committee'? They are
nothing but simple arrays... Also, to make things worse, technically,
'theOrganization' should be a singleton... :)
Now, to get the data out of the MySQL database, it is probably more
efficient to do as few SQL selects as possible. Efficient from a speed
point of view. However, from a coding/OO-style point of view, it makes
more sense to have each People object be defined as *one* person -- but
that would mean that each has data for only one person and that would mean
a separate SELECT statement for each People object created. (Assuming that
there is a SQL SELECT in the constructor of each People object or
something similar to that).

Traditionally (i.e. non-OO), to code this, I would do as few SQL calls as
possible. But I can't see how to do that from an OO point of view.
Which leads me to asking, why do you want OO design here in the first
place, if it is to result in lousy performance? Sounds like you are
deliberately setting yourself up for a failure...
For example, does it make sense to put all the people data into an array
outside of the People class and use this list to set up the class
constructor? (It doesn't make sense to me)

Or, for example, does it make sense to have the People class just be a
list of *everyone* in the people table? (This too does not make sense to
me)

On the other hand, what is the performance impact if I *do* make each
People class instance be only *one* person?

These questions would make sense if you were writing a desktop
application. But you're not; by choosing PHP as your development
tool, you have automatically abandoned the traditional concept of
application. You are not designing a monolythic package; rather,
you need to come up with a collection of relatively independent
utilities or modules, each suited for a narrowly defined task.
Until you figure out what those tasks are, you won't be able
to come up with a decent design.

Cheers,
NC

[Neil White]

Hi Jeffrey

I am designing a smallish application to manage members of several
committees of a particula Organization. The structure of the system is as
follows:
theOrganization
contains Committees
which in turn contain People

So theOrganization object is a list of Committee objects which are
themselves groups of People objects.

Now, to get the data out of the MySQL database, it is probably more
efficient to do as few SQL selects as possible.
&c

Don't struggle with this.

Design your objects with a proper hierarchy.
Trust your database engine - you have no choice unless you build it
yourself.
Address the database engine properly using your preferred language with
correct reference objects.

And get on with things. :-)

Best regards,
Neil

[Jeffrey Silverman]

On Mon, 11 Aug 2003 23:39:11 +0100, Neil White wrote:

<snip!>

Don't struggle with this.

okay, thanks, I won't
Design your objects with a proper hierarchy. Trust your database engine -
you have no choice unless you build it yourself.
Address the database engine properly using your preferred language with
correct reference objects.

And get on with things. :-)

Okay, thanks. In fact, I already have. And it turns out that I think I was
needlessly concerned.

But that's okay -- I just wanted some general opinions in this regard. And
I got some.

later...

--
Jeffrey D. Silverman | jeffrey AT jhu DOT edu
Johns Hopkins University | Baltimore, MD
Website | http://www.wse.jhu.edu/newtnotes/