Форум MySQL

В процессе написания форума возник вопрос: как лучше с точки зрения скорости работы и загруженности хранить информацию о числе сообщений в теме...

1) либо каждый раз считать их число в БД при формировании соотв. числа для вывода на экран;
2) либо записывать это число с столбец БД, чтобы если нужно его просто читать, а при добавлении(удалении) темы увеличивать или уменьшать это значение соответственно?

Лучше второй вариант, пусть он более трудоемок, однако если база данных форум достигнет большого объема - с первым вариантом хлебнете лиха.

Вот я тоже об этом подумал...
Просто у Вас в книге описан первый вариант... я задумался, а не быстрее ли будет работать второй вариант... вот и решил спросить

Они будут работать примерно одинаково при любых объёмах таблиц, если при первом варианте правильно построить структуру БД и создать индексы.

Если нет возможности перейти на выделенный сервер, где можно настроить и полностью занять кэши, варианты будут эквивалентны примерно до 200 Мб - потом будет выигрывать второй вариант. Сканировать каждый раз пусть даже проиндексированную 200 Мб таблицу сложнее, чем просто взять из неё готовое число, подсчитанное при добавлении.

Для создания системы кеширования SQL-запросов совсем не обязательно нужен свой сервер. Это можно сделать на уровне PHP.

Можно. Однако, его поддерживает и MySQL, причем гораздо более эффективно (нужно только память под этот кэш выделить).

Лучше первый вариант. Во-первых, как сказали, необходимо просто правильно построить структуру таблицы и проставить индексы. Во-вторых, можно и кешировать SQL-запросы.

> с первым вариантом хлебнете лиха
Я бы сказал, что хлебнуть с полна можно со вторым вариантом.

Это действительно от структуры базы зависит, может так статься, что ни кэш, ни индексы не спасут, только выделенный сервер. Если нужна скорость на таблицах объемом в несколько сот мегабайт - эффективнее денормализация (второй вариант). Иначе индексы и содержимое придётся разносить по разным таблицам (вот в этом случае действительно со вторым вариантом можно хлебнуть).

PS Денормализация обычная практика, когда нужна скорость, а уж в случае трудоемких запросов на подсчет количества сообщений - сам бог велел, тем более не так уж сложно это реализовать.

Важный момент - человек хочет подсчитывать сообщения в теме. Тут не требуется сортировка, тут наврядли будет огромное количество записей для одного ключа, а отсюда скорость будет очень неплохая и при миллоне записей, и при двух миллонах и, возможно, даже при еще большем количестве. Говорю не голословно, у меня у самого на одном проекте есть таблица, где около 900000 (размер ~ 150 Mb) записей и всё работает вполне нормально. Причём, там нет кеширования, я во время проектирования был еще совсем глупеньким.

Может работать, а может и нет, особенно там, где кэш нет возможности применить. У нас тоже все нормально было, пока не попали на мастерхосте на сверх-загруженный сервер. Проблему администраторы решили, однако не сразу, а за три недели (вы вероятно ещё помните ситуацию в мае-июне). Пришлось вводить денормализацию - просто подсчитать количество всех сообщений в теме, что позволило значительно ускорить работу приложения. Хотя в штатном режиме, что предыдущий, что существующий варианты работают без проблем.

PS Кстати, лишнее поле с количеством сообщений в теме, если отбросить высокие слова, кэшем и является.