Лишний запрос или лишнее поле в таблице?
Я вот тут чет посидел, подумал и запутался:)
Решил перелопатить свою CMS-ку и вот над чем задумался.
Имеем таблицу со статьями. Статья может иметь неограниченное кол-во допустимых комментариев и прикреплененных картинок. Картинки и комментарии, соответственно, хранятся в других таблицах.
При открытии картинки мы считываем саму статью из БД, потом дергаем картинки и комментарии. Но порой бывает, что картинок и комментариев к статье нет, т.е. тем самым мы попросту делаем холостой запрос к БД. Так может стоит завести 2 поля-флага в таблице со статьями: hasImages (да/нет), has Comments(да/нет)? И в зависимости уже от этих флагов решать - слать запросы или нет.
Вот насколько это оправдано и разумно? С одной стороны - лишние поля таблице, но с другой - большая эффективность.
ЗЫ: естественно, вопрос рассматривается относительно сильно нагруженных проектов, так как только в этом случае можно получить какой-то значимый прирост КПД.
ЗЫЫ: естественно, что помимо запроса к статье, существует ещё n различных запросов к серверу (модули, статистика + прочее)
Решил перелопатить свою CMS-ку и вот над чем задумался.
Имеем таблицу со статьями. Статья может иметь неограниченное кол-во допустимых комментариев и прикреплененных картинок. Картинки и комментарии, соответственно, хранятся в других таблицах.
При открытии картинки мы считываем саму статью из БД, потом дергаем картинки и комментарии. Но порой бывает, что картинок и комментариев к статье нет, т.е. тем самым мы попросту делаем холостой запрос к БД. Так может стоит завести 2 поля-флага в таблице со статьями: hasImages (да/нет), has Comments(да/нет)? И в зависимости уже от этих флагов решать - слать запросы или нет.
Вот насколько это оправдано и разумно? С одной стороны - лишние поля таблице, но с другой - большая эффективность.
ЗЫ: естественно, вопрос рассматривается относительно сильно нагруженных проектов, так как только в этом случае можно получить какой-то значимый прирост КПД.
ЗЫЫ: естественно, что помимо запроса к статье, существует ещё n различных запросов к серверу (модули, статистика + прочее)
Добавь два поля для счетчиков. В одном храни количество картинок для данной статьи, во втором количество комментариев. И при выборке из базы смотри их отличие от нуля.
Естественно лучше еще одно поле, чем запрос к бд... и вот почему.
Запрос к бд типа SELECT это достаточно долгая операция если у тебя большая таблица. На это нужно достаточно времени. Тажке БД может быть реализована на другой машине и плюс к этом появляется сетевая задержка.
А поле делай одно и в виде битового поля.
0 - ни картинки, не статьи
1 - есть картинки, нет статей
2 - есть статья, нет картинок
3 - есть и то, и то.
Производительности это конечно добавит, но только для статей без комментов и картинок. А вот для статей которые с картинками и с коментариями производительность будет меньше потому что ты всё равно обращаешься в БД и еще к тому же вычисляешь в скрипте нужно ли это обращение.
В общем если у тебя много "пустых" статей то это имеет смысл.
А если на 50-100 полноценных будет приходится одна "пустая" то скорей всего ниче не выиграешь!
В любой случае ты можешь всё это посчитать на калькуляторе и замерив время выполнения каких то отдельных частей скрипта. Я могу тебе расписать по подробней как это всё делается, если ты не знаешь как это сделать или не хочешь идти "своими путями".
Запрос к бд типа SELECT это достаточно долгая операция если у тебя большая таблица. На это нужно достаточно времени. Тажке БД может быть реализована на другой машине и плюс к этом появляется сетевая задержка.
А поле делай одно и в виде битового поля.
0 - ни картинки, не статьи
1 - есть картинки, нет статей
2 - есть статья, нет картинок
3 - есть и то, и то.
Производительности это конечно добавит, но только для статей без комментов и картинок. А вот для статей которые с картинками и с коментариями производительность будет меньше потому что ты всё равно обращаешься в БД и еще к тому же вычисляешь в скрипте нужно ли это обращение.
В общем если у тебя много "пустых" статей то это имеет смысл.
А если на 50-100 полноценных будет приходится одна "пустая" то скорей всего ниче не выиграешь!
В любой случае ты можешь всё это посчитать на калькуляторе и замерив время выполнения каких то отдельных частей скрипта. Я могу тебе расписать по подробней как это всё делается, если ты не знаешь как это сделать или не хочешь идти "своими путями".
Ну объяснять мне, почему обращения к БД долги - этого не надо) Я это и так знаю)
А вообще остановлюсь на варианте со счётчиком - более оптимально и практично. Странно, что сам до этого не додумался))
А вообще остановлюсь на варианте со счётчиком - более оптимально и практично. Странно, что сам до этого не додумался))
Только на всякий случай добавь функцию пересчитывания счётчиков :) А то они могут иногда и сбиваться, вдруг где-то что-то будет автоматически удаляться не учитывая новую структуру базы или ещё что-то подобное.
Ну это понятное дело=)
Цитата: UAS
Ну это понятное дело=)
Поздравляю, вы на ровном месте придумали себе дополнительную проблему :)
Цитата: RussianSpy
Добавь два поля для счетчиков. В одном храни количество картинок для данной статьи, во втором количество комментариев. И при выборке из базы смотри их отличие от нуля.
И что это интересно даст? RussianSpy пиши пожалуйста поконкретней (я совершенно не понимаю что дадут эти счетчики) а то я начинаю думать, что ваше самомнение а амбиции превыше ваших переживаний за производительность и стабильность.
Я могу ответить за него. По крайней мере для меня - счетчики в разы удобнее. Очень часто, а практически и всегда, при выводе информации о статье (не самой статьи) выводится статистика: сколько в ней комментов и сколько фотографий. Это очень распространенно. Так зачем лишний раз дергать БД в виде запроса SELECT COUNT(*), когда все хранится в поле.
[QUOTE="hardcase"]Поздравляю, вы на ровном месте придумали себе дополнительную проблему[/QUOTE]
Да там ничего проблематичного) Раз в неделю в самое ненагруженное время выбрать, допустим, последний 150-200 записей (больше, я думаю, смысла и не имеет) и проверять их в течение часа поочередно (ну чтобы не было единовременной нагрузки сильной).
Хотя, если все предусмотреть в скрипте и руки отттуда, откуда надо, то такой проблемы и не будет=)
[QUOTE="hardcase"]Поздравляю, вы на ровном месте придумали себе дополнительную проблему[/QUOTE]
Да там ничего проблематичного) Раз в неделю в самое ненагруженное время выбрать, допустим, последний 150-200 записей (больше, я думаю, смысла и не имеет) и проверять их в течение часа поочередно (ну чтобы не было единовременной нагрузки сильной).
Хотя, если все предусмотреть в скрипте и руки отттуда, откуда надо, то такой проблемы и не будет=)
Кстати хм... я не врубаюсь зачем тебе знать количество картинок в статье? Если я правильно понял, то картинки (фотки) выводятся в самой статье? А у тебя во второй БД сами фотки или ссылки на них?
Я могу предположить что статья с картинками у тебя выводится на странице A.
А комментарии к статье на странице B. Но на странице А пишется число комментов.
Правильно?
Я могу предположить что статья с картинками у тебя выводится на странице A.
А комментарии к статье на странице B. Но на странице А пишется число комментов.
Правильно?
Цитата: Слава Великолепный
И что это интересно даст? RussianSpy пиши пожалуйста поконкретней (я совершенно не понимаю что дадут эти счетчики) а то я начинаю думать, что ваше самомнение а амбиции превыше ваших переживаний за производительность и стабильность.
Счетчики дадут информацию о наличии либо отсутствии данных. В нашем случае картинок. Если бы вы хоть раз писали высоконагруженные проекты -вы бы это знали.
Подобные счетчики позволяют "размазать" тяжелые вычисления по времени. Когда у вас в таблице 15 миллионов записей, разбитых по нескольким тысячам категорий, то лучше считать один раз при добавлении данных в категорию чем много раз при запросах выборки. Здесь, конечно, не миллионы записей, но все равно даст определенные небольшие плюсы.
Цитата: Слава Великолепный
что ваше самомнение а амбиции превыше ваших переживаний за производительность и стабильность.
Если б у него было это вмененное "самомнение и амбиции" во вмененном же объеме, он бы взял ник типа RussianSpy Великолепный, можете не сомневаться. :D
Цитата: Слава Великолепный
Кстати хм... я не врубаюсь зачем тебе знать количество картинок в статье? Если я правильно понял, то картинки (фотки) выводятся в самой статье? А у тебя во второй БД сами фотки или ссылки на них?
Я могу предположить что статья с картинками у тебя выводится на странице A.
А комментарии к статье на странице B. Но на странице А пишется число комментов.
Правильно?
Я могу предположить что статья с картинками у тебя выводится на странице A.
А комментарии к статье на странице B. Но на странице А пишется число комментов.
Правильно?
Список статей выводится массово (например, список статей в разделе). Плюс к названиям статей выводится статистика, которой необходимо использовать вот эти данные счетчика.
2UAS:
Можете смело делать счетчики. Это весьма распространенная практика на средних, крупных и очень крупных ресурсах. Всегда стараются свести затраты на расчет каждой страницы к минимуму, а подобные счетчики позволяют сэкономить порой до 90% процессорного времени.
Кто не верит - попробуйте на досуге запустить какой-нибудь сложный запрос с агрегирующими функциями на таблицах в 35-50 миллионов записей.
Можете смело делать счетчики. Это весьма распространенная практика на средних, крупных и очень крупных ресурсах. Всегда стараются свести затраты на расчет каждой страницы к минимуму, а подобные счетчики позволяют сэкономить порой до 90% процессорного времени.
Кто не верит - попробуйте на досуге запустить какой-нибудь сложный запрос с агрегирующими функциями на таблицах в 35-50 миллионов записей.