Er det bedre at filtrere et resultatsæt ved hjælp af en WHERE-klausul eller ved at bruge applikationskode?

Tommelfingerreglen for enhver applikation er at lade DB'en gøre de ting, den gør godt:filtrering, sortering og sammenføjning.

Adskil forespørgslerne i deres egne funktioner eller klassemetoder:

$men = $foo->fetchMaleUsers();
$women = $foo->fetchFemaleUsers();

Opdater

Jeg tog Stevens PostgreSQL-demonstration af en fuld tabelscanningsforespørgsel, der var dobbelt så god som to separate indekserede forespørgsler og efterlignede den ved hjælp af MySQL (som bruges i selve spørgsmålet):

Skema

CREATE TABLE `gender_test` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `gender` enum('male','female') NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=26017396 DEFAULT CHARSET=utf8

Jeg ændrede kønstypen til ikke at være en VARCHAR(20), da den er mere realistisk til formålet med denne kolonne. Jeg giver også en primær nøgle, som du ville forvente på en tabel i stedet for en vilkårlig DOBBEL værdi.

Uindekserede resultater

mysql> select sql_no_cache * from gender_test WHERE gender = 'male';

12995993 rows in set (31.72 sec)

mysql> select sql_no_cache * from gender_test WHERE gender = 'female';

13004007 rows in set (31.52 sec)

mysql> select sql_no_cache * from gender_test;

26000000 rows in set (32.95 sec)

Jeg stoler på, at dette ikke behøver nogen forklaring.

Indekserede resultater

ALTER TABLE gender_test ADD INDEX (gender);

...

mysql> select sql_no_cache * from gender_test WHERE gender = 'male';

12995993 rows in set (15.97 sec)

mysql> select sql_no_cache * from gender_test WHERE gender = 'female';

13004007 rows in set (15.65 sec)

mysql> select sql_no_cache * from gender_test;

26000000 rows in set (27.80 sec)

Resultaterne vist her er radikalt forskellig fra Stevens data. De indekserede forespørgsler udfører næsten dobbelt så hurtigt som fuld bordscanning. Dette er fra en korrekt indekseret tabel, der bruger sund fornuft kolonnedefinitioner. Jeg kender slet ikke PostgreSQL, men der må være en væsentlig fejlkonfiguration i Stevens eksempel for ikke at vise lignende resultater.

I betragtning af PostgreSQL's ry for at gøre ting bedre end MySQL, eller i det mindste lige så godt som, tør jeg godt sige, at PostgreSql ville demonstrere lignende ydeevne, hvis den blev brugt korrekt.

Bemærk også, på denne samme maskine tager en alt for forenklet sløjfe, der udfører 52 millioner sammenligninger, yderligere 7,3 sekunder at udføre.

<?php
$N = 52000000;
for($i = 0; $i < $N; $i++) {
    if (true == true) {
    }
}

Jeg synes, det er ret indlysende, hvad der er den bedste tilgang givet disse data.