Question

I have a single table that contains two types of items under the same class/category. I want to use php to output two lists, each containing each type of item. Would it be generally faster and more acceptable to sort them by using two queries or just query them all and then just PHP to sort them using if($type == 'blah') statements?

Which is generally more recommended/acceptable?

I am aware of benchmarking but I would like a general opinion/standard, as benchmarking can usually be very dependant on other factors.

Sample result set

entry_id   user_id  element_id  saved_date  saved_type
    65     1         20         1315473732  listing
    66     1         22         1315473735  listing
    49     1         5          1315429549  user
    62     1         1          1315470500  user
    70     1         15         1315473763  listing
    72     1         2          1315476924  listing

In general, results shouldn’t exceed more than 100 records in total. Example output is basically this result set separated into two tables “Saved Listings” and “Saved Users”.

Answer 1

Ease of understanding
I think it’s a bad pattern if you write complicated code in php, that can be trivally coded in SQL, see @Col Shrapnel’s answer.

The top SQL statement

$type1 = $db->getArr("SELECT * FROM table WHERE type=1");

is instantly clear: get all items with type = 1.

The bottom one requires scanning. Also note that @Col shrapnel’s top and bottom code samples are not 100% equivalent! This is a minor oversight I’m sure, but sometimes it can be really hard to write equivalent code to SQL in php, SQL differs in subtle ways from procedural logic that can be very hard to grok.
SQL wins

Network load
Running tiome is one time thing, but you also need to take network load into account.
If you do a select * and then soft out the results in php, that means data (may) need to cross the network, a very slow medium.
This is a waste of resources and the network time can easily outweigh all other time factors.
SQL wins

Pure running time
This is a hard one too call, SQL has indexes on the data that it can (re)use to sort the data, however sometimes it does too much work and php will be a faster choose.
I would contest though that because SQL has more information available (in the form of indexes) to handle the data fast.
There are also (many) tricks you can use e.g. SQL_SMALL_RESULT to force MySQL to keep the data in memory and not use disk for temp-storage.
To close too call

Architecturally
If you design an application, and the underlying database changes, which option would make be easier to redesign, which is more robust.
If you do all the work in SQL and always present standardized results to php, you can seperate the php code from the database.
If you do half your database processing in php, you lose that advantage.
This kind of tight coupling between the raw database and php is a clear fail in my opinion and a well known anti-pattern.
SQL wins

Closing argument
I can go on, but I would like to rest my case and declare SQL the clear winner.
php can maybe score a few points on a minor issue, but I doubt the few cases where it is faster are sufficiently important to overcome the disadvantages you are heaping on your project.
I think you are also underestimating the many ways in which SQL can be optimized.