Не секрет, что я при создании движка серьезно озабочен производительностью. О скорости и памяти вы можете судить уже сейчас. Хочется добиться аналогичных результатов и для бд. Один из путей оптимизации - уменьшение количества sql запросов на странице.

Сегодня тестировал страницу поста с комментами - вначале было 16 запросов. Посмотрел все запросы - уменьшил до 14. Все равно как то многовато. Половина запросов относятся к комментариям. Желателен вариант, когда за один запрос получаются все нужные комментарии. Но не обязательно - mysql это кривожопая СУБД. На сложных запросах она катострафически теряет производительность. Я всегда помню об этом и стараюсь не делать сложных запросов для mysql. Для нее зачастую бывает быстрее сделать два отдельных запроса, чем один.

В версии на файлах есть проверка - показывать ли линк на автора коммента, для чего проверяется количество уже одобренных комментов. Очевидно, что для списка комментариев в бд придется делать вычисления , которые будут прогрессивно расти. С другой стороны речь идет об абстракции - доверие пользователю, что он спамер или нормальный комментатор. Ввел новое поле в таблице trust - число, показывающее уровень доверия к комментатору. Пока что его применение это показывать или нет линк. Аналог в других движках -- карма. Карма не нравится, в том смысле, что мне кажется это будут разные цифры - траст и карма. Например для трастовых комментаторов можно было бы вообще не показывать форму подтверждения (идея возникла только что, во время написания этих строк).

Также возник вопрос о дублях комментов. Для бд делать полнотекстовый поиск соответствия означало бы просто обвалить бд. Но если речь идет о больших текстах, то всегда может выручить MD5 - 32 символьная строка или 4 слова. Для бд подойдет как раз строковое представления хеша, и соответственно полнотекстовый поиск сведется к поиску хеша. Сырой контент и хешь хранится в отдельной таблице - сами комментарии и сырой контент разделены ради производительности. Также разделены комменты и авторы комментов. Траст Относится не комментарию, а к автору комментария, так что уже сейчас нет никаких сомнений в целесообразности разделения комментариев и авторов. Что касается сырого контента, то желательно было бы разделить это и в версии на файлах, где сейчас они хранятся вместе.

Свойства trust в версии на файлах пока отсутствует и я что то не хочу его туда вводить, так тогда часто придется сохранять данные комюзеров, но в принципе возможно.

То, что я писал в предыдущем посте о шаблонах и формате даты я уже реализовал, и все работает, поэтому я занялся дальнейшими исследованиями версии на бд.