известнейшая ситуация, когда товарищ перед отправкой в БД данных пропускает их через htmlspecialchars, и тогда мы дружно говорим, что в БД нужно хранить исходные данные, даже если мы говорим только о bb-кодах

и тут меня торкнуло /говорим только о bb-кодах/

посмотрим на примере этого форума.
участник отправляет пост, он в исходном состоянии складируется в БД, а затем при каждом извлечении проходит обработку.

это же эхма как не экономно, и что-то мне кажется, это очень не экономно.

вопрос: почему же всё-таки не хранить пост в уже переработанном в хтмл виде? 

захотел пользователь его отредактировать - распарсится этот хтмл обратно, но то же 1 раз и то не всегда, а не по 100 раз обработка на каждый пост.

короче, не догоняю

эм... мне всегда казалось что в БД храниться уже готовый html

1) А если парсер перенастроили? Запретили например один тег? Или ошибку в теге поправили? Или новый ввели?
2) А если надо редактировать пост?

Есть вариант такой: хранить в исходном и обработанном виде(кэш), но его сбрасывать при каждом чихе.
Однако это не вполне удобно: допустим мы сбросили кеш, а потом что, инсертить будем обратно?)
1) Усложнит архитектуру - это же надо пачкой потом инсертить.
2) Единичная обработка куда уж быстрее инсерта.


Поэтому можно просто не заморачиваться. Это не сложная операция и явно не является ботлнеком.

Статья про оптимизацию: http://rsdn.ru/article/philosophy/Optimization.xml

Готовый лудще ...
Надо будет отредактировать так один рас распарсишь хтмл на свои любимые bb коды а запрещенные теги шифт+делет.
Мое мнение принимать в BB кодах переводить его в ХМТЛ при редактирование парсить ХТМЛ обратно в ББ коды. 
1 функцией больше зато не нужно парсить текст каждый раз при ввыводе сообщения и  

 Это:
По меньшей мере глупо по трудозатратам: хороший парсер на регекспах не написать, придется писать громоздкие алгоритмы, уйдет несколько дней. А для чего? Для того, чтобы сэкономить полкилобайта места на харде? о_О

+ остаются те же проблемы:

Не понимаю, какой смысл спорить

переписали структуру, админ жмёт кнопку и бегунок один раз пробегает по базе и переписывает в нужном ключе. распарсили, провели новую обработку, записали


один раз распарсили и всё. имхо, по нагрузке 1 раз распарсить хтмл легче, чем сто раз проводить обработку на выдаче.


ну, это как бы единственный довод, который мне виден. примеры под такую систему уже расписаны


ну, во-первых, вроде никто не спорит, а по-вторых, этож концепт - то бишь принятие решения, как оно всё будет



а если наоборот, производить дубликат. таблица с переработанными в хтмл постами, и плюс таблица с исходным текстом для редактирования?

хотя всё равно не вижу причин почему бы не парсить текст исключительно для редактирования и переписывания при изменении структуры тэгов. 

 Т.е. придется писать отдельную утилиту еще, как-то синхронизировать ее... Не с веба же такой скрипт запускать ))

 Я не про тоговорил, а про то, что исходный надо обязательно держать.

 Я именно про это и сказал. Но все равно это не исключает перегенерации всех/нужных постов.

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

интересно было бы оценить работу реальной системы
и ещё, что там Вова постоянно оптимизирует, что сервер перестаёт тормозить?