По-добре ли е да филтрирате набор от резултати с помощта на клауза WHERE или с помощта на код на приложение?

Основното правило за всяко приложение е да оставите DB да прави нещата, които прави добре:филтриране, сортиране и обединяване.

Разделете заявките на техните собствени функции или методи на клас:

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

Актуализация

Взех демонстрацията на PostgreSQL на Стивън за заявка за сканиране на пълна таблица, която се представя два пъти по-добре от две отделни индексирани заявки, и я имитирах с помощта на MySQL (което се използва в действителния въпрос):

Схема

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

Промених типа на пола да не бъде VARCHAR(20), тъй като е по-реалистично за целите на тази колона, предоставям също първичен ключ, както бихте очаквали в таблица, вместо произволна стойност DOUBLE.

Неиндексирани резултати

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)

Вярвам, че това няма нужда от обяснение.

Индексирани резултати

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)

Показаните тук резултати са радикални различни от данните на Стивън. Индексираните заявки изпълняват почти два пъти по-бързо от пълното сканиране на таблицата. Това е от правилно индексирана таблица, използваща здрави разумни дефиниции на колони. Изобщо не познавам PostgreSQL, но трябва да има някаква значителна грешна конфигурация в примера на Стивън, за да не се показват подобни резултати.

Като се има предвид репутацията на PostgreSQL, че прави нещата по-добре от MySQL или поне толкова, смея да твърдя, че PostgreSql ще демонстрира подобна производителност, ако се използва правилно.

Също така имайте предвид, че на същата тази машина прекалено опростен for цикъл, извършващ 52 милиона сравнения, отнема допълнителни 7,3 секунди за изпълнение.

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

Мисля, че е доста очевидно кой е по-добрият подход предвид тези данни.