Допустим, имеем классический блог: статьи, комментарии.
Один SQL запрос, чтобы выбрать все статьи для главной страницы, комментарии не нужны, тут всё ясно понятно.
Открываем статью, необходимо сделать выборку и статьи, и комментариев к ней.
Вариант первый, — сделать один запрос чтобы достать статью, затем второй запрос, чтобы достать все комментарии к ней.
Вариант второй, — один запрос, в котором мы достаём статью и тут-же JOIN'им таблицу с комментариями к ней, затем, при выводе данных на страницу, уже должен скрипт сам в цикле пройтись по результату, и отобразить статью один раз, а оставшиеся комментарии в остатке.
Как лучше? Два SQL-запроса против одного с JOIN.
Добавим к этому ещё одну таблицу загруженных картинок к постам и комментариям. При открытии статьи уже придётся делать либо три запроса, либо один запрос с JOIN'ом двух таблиц.
Таблица с загруженными картинкам относится к комментариям тоже, представьте, обсуждение на 1000 комментариев: не делать же на каждый комментарий целый SQL-запрос, чтобы выбрать все картинки к нему, ага? То есть, вариант остаётся только один: JOIN'ить все три таблицы, затем одним циклом распределять все данные между тремя различными массивами (статья, комментарии, картинки), и уже затем только выводить данные из этих циклов, после обработки.
Имеются ли ещё какие-то варианты?
Стоит ли беспокоиться о расходуемой скриптом памяти? Статья, 1000 комментариев, по 10 картинок к каждому. Вместо того, чтобы плавно обращаться к БД и тут-же выводить данные, все эти данные будут предварительно записаны в массивы, пусть и на короткое время, но всё же памяти они съедят прилично, не так ли?
Вот и не знаю как поступить.
В любом случае, запросов к БД необходимо делать как можно меньше, а вся работа должна ложиться на скрипт, в котором первым циклом мы только достаём данные из БД и разносим их по разным массивам, и только потом выводим, уже из этих массов. Так?
