1

Currently, I build two classes for each database table. For instance, if I have the table person, I will have the classes Person_List and Person.

Design-wise, is it better

  1. for Person_List to output an array of Person; or
  2. for it to output an array containing arrays of rows in the table.

Performance-wise, which is better?

mauris
  • 42,982
  • 15
  • 99
  • 131
Dave
  • 3,328
  • 7
  • 26
  • 30

3 Answers3

2

I believe that design-wise, and taking performance into account, would be to (if you insist on Person_List class to represent table and Person to represent single record):

  • use Iterator interface for Person_List class, so you can iterate through the table without the need to pull all the records at once (it should be significant performance gain in some cases),
  • additionally use Countable interface for Person_List class, so you are able to count all the results if necessary by getting count directly from database,

This should give you flexibility and allow you to use Person_List class objects similarly as arrays.

If you still have problems employing these two interfaces, here is some explanation:

  • every time you do foreach ($table as $record) (where $table is an instance of Person_List), the current() method of Person_List class will be invoked (because it is a part of Iterator interface - see docs here), which should return an object of Person class; this should happen using eg. mysql_fetch_object();
  • when you call count($table) (where $table is an instance of Person_List), the count() method of Person_List class will be invoked, which in turn can use eg. mysql_num_rows() function to return all the results instead of pulling them from database and then counting (this will be again significant performance gain),
Tadeck
  • 132,510
  • 28
  • 152
  • 198
  • From a memory standpoint, `Iterator` would give him a perf gain. however, it can be a bit slower in iteration cost. – Adam Wagner Nov 12 '11 at 08:09
  • @AdamWagner: The issue here may be the number of records in the database. If it is significant number, there may be no other way than just get records one-by-one instead of all at once. – Tadeck Nov 12 '11 at 08:18
  • If it is, then this is generally the right solution. It's just sometimes the overhead of the additional user-space calls (for very high number of iterations) can be surprising. – Adam Wagner Nov 12 '11 at 08:25
  • I'll try these suggestions using a table with 10000 entries. – Dave Nov 12 '11 at 09:09
  • @Dave: Do you have to iterate through all of the records at once? – Tadeck Nov 12 '11 at 09:33
  • No, just around 50 rows per page. I'm just worried that each page load would cause 50 db calls. Please correct me if I'm wrong. – Dave Nov 12 '11 at 10:06
  • @Dave: You should not be worried about that - there is only one query, which is executed only one time (if, of course, not invoked again), and you only get each row separately as you would by quite common practice such as `while($row=mysql_fetch_array($res)) {...`. The function just pulls one record using some low-level API of MySQL, does not execute another query. – Tadeck Nov 12 '11 at 12:54
0

It really depends on what you are doing with the records. Accessing columns on the records shouldn't be much (any?) faster to use arrays. Not enough to justify not using objects

Arrays are lighter (smaller in memory, especially) than objects, but if you use Iterator like @Tadeck mentions, this shouldn't be an issue, as you'd only have one instance in memory at a time.

In summary, objects are almost always a better design (from an interface standpoint), however, if you are not sure from a performance standpoint, benchmark the candidate implementations. If the difference isn't noticeable enough, use objects.

Community
  • 1
  • 1
Adam Wagner
  • 15,469
  • 7
  • 52
  • 66
0

You tagged this OOP so I guess you want to work with objects. In that case you'd want to have it return PersonRow objects, e.g. objects that represent a row in the db table. Have a look at

You should not worry about performance. Come up with a solid design that is readable and maintainable. Only bother about performance when you put your design into action, profiled it and found it doesnt meet performance requirements.

Gordon
  • 312,688
  • 75
  • 539
  • 559