I think perhaps I'm using classes and OOP incorrectly. The last time I used them, they were slow.
I want to create a "customer" class which fetches its attributes from a MySQL database. Something
like this pseudocode:
class customer
{
...
getName ($id)
{
$result = mysql_query ("SELECT name FROM customers WHERE id = '$id'");
return mysql_result ($result, 0);
}
getRevenue ($id,$department,$month,$year)
{
$result = mysql_query ("SELECT revenue FROM customer_revenue WHERE customer_id = '$id' AND
department = '$department' AND month = '$month' AND year = '$year'");
return mysql_result ($result, 0);
}
...
}
(Again, that's just psedocode. Haven't written anything yet.)
That works great for just one revenue result, but what if I want to return several results? What
if I want to build a report with hundreds of customers' revenues for a month? For several months?
For an entire year? Doesn't it slow wayyyy down? It seemed to in the past. The method above
doesn't seem to scale well.
I did something like the above a few years ago. It was slow, and I think it's because it was
doing this for each single row:
* Instantiate the class
* Perform a query for the name
* Perform a query for the first department
* Perform a query for the next department
* Perform a query for the next department
* Perform a query for the next department
* Perform a query for the next department
* Perform a query for the next department
* Perform a query for the next department
...
* Destroy the instantiation
* Start over
I love using object-oriented programming, but it seems to me that's ALOT of performance burden
when I could just do something like this:
SELECT customers.name,
customer_revenue.revenue
FROM customers
INNER JOIN customer_revenue
ON customers.id = customer_revenue.customer_id
WHERE customer_revenue.department = '$department'
AND customer_revenue.month = '$month'
AND customer_revenue.year = '$year'
(PHP loop to display all results)
That seems like it would perform 20x faster.
It seems that the SQL economies of scale (ability to rapidly slurp large sets of data) are
completely bypassed when using OOP to view ALOT of objects together on one screen. It seems if I
want decent performance I would have to ignore OOP rules of method hiding and access the data
directly when using anything more than just a few objects on one page.
A workaround -- I thought that perhaps I could fetch ALL of the data for a customer into memory
upon initial instantiation, wherein I perform something like this:
SELECT *
FROM customers
INNER JOIN customer_revenue
ON customers.id = customer_revenue.customer_id
WHERE customers.id = '$id'
And then use the results from memory as-needed. It would be all data for a customer from all
years across all departments.
That might perform better but it'd suck ALOT of data into memory, and what if I add more than just
revenue to my customer class? Each customer could potentially represent a limitless set of data.
So this doesn't seem like an optimal solution.
* Where am I going wrong?
* Tell me how YOU fetch data from multiple objects to generate reports.
* Is this an instance where it's better to just ignore OOP rules and go straight to the data?
Whew, that's not fun to think about, particularly if my queries ever get to be more complex.
Feedback, please. The goal is to maintain complex queries in just one place -- inside a class. I
want my data to _only_ be accessed from the black box called an OOP class.
CD
Think you're a good person? Yeah, right! ;-)
Prove it and get ten thousand dollars:
TenThousandDollarOffer.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
