Сразу поясню, почему я использовал один запрос

Сразу поясню, почему я использовал один запрос. Идея в том, что на страницах баг трекера всегда должны отображаться и баги и комментарии. После загрузки страницы все комментарии будут автоматически сворачиваться (с помощью JS) и посетитель увидит только заголовки. При клике по заголовку список комментариев будет развернут. Это должно увеличить скорость работы со страницей, т. к. подгружать комментарии с помощью отдельных запросов не придется. Разбить на 2 массива таблицу можно, но не уверен, что такой вариант был бы намного проще. В этом случае пришлось бы: 1) для каждого бага найти соответствующие ему комментарии во втором массиве; 2) с помощью рекурсивной функции построить деревья для каждой группы комментариев. Вариант, который приведен в статье на sitepoint. com, конечно, выглядит гораздо красивее и короче. Но при этом возникает ситуация, которой я хотел избежать. Автор той статьи предлагает выполнять запросы внутри рекурсивной функции, а это означает, что если у нас есть десять вложенных комментариев, то для их получения будет выполнено 10 запросов. Т. е. может получиться, что мы будем "тянуть" из базы комментарии по одному. Не думаю, что между ZendFW и CI в этом плане есть разница. Во всяком случае CI не накладывает своих ограничений на работу с БД. И я конечно не предлагаю использовать такой запрос для страниц на которых не нужны комментарии. Этот пример касается только страницы с общим списком. Для формирования RSS ленты или страницы с отдельным багом я добавлю дополнительный метод в модель, который будет получать, например, только заголовки багов из БД. >> Зачем нам столько лишних данных? Вот тут вы абсолютно правы. Это основной недостаток данного подхода. Проблема в том, что использовать LIMIT не получается, т. к. количество записей определяется числом комментариев, а не багов. А разбивка на страницы осуществляется именно по количеству багов. По-моему, должен быть какой-то способ решить эту проблему. Вариант с получением списка багов, а потом отдельно комментариев для каждого бага, конечно, проблему решает, но мне хотелось избежать выполнения запросов в цикле. Хотя, может быть я тут не прав. Нужно потестировать скорость выполнения этих вариантов.

Понравилась статья? Получай обновления и будь всегда в курсе событий!
Подпишись на RSS или
blog comments powered by Disqus