| jcrush |
|
|---|---|
|
Заметил что в таблице постов форума, как подозреваю и страницах мы храним два раза один и тот же текст - тело сообщения 1. в text и html, как я понимаю это надо для ббкоде, но все же за счет этого вся база в 2 раза растет неоправданно, разве других решений нет?
`sed_forum_posts` - `fp_html SEO блог: http://blog.stfw.ru/
|
| Sergeich |
|
|---|---|
|
В поле html хранится отпарсеный ББ-код, собственно, это тот самый html-кеш :). При формировании страницы движок берёт готовый кусок кода, а не парсит каждый раз ББ.
|
| Boss |
|
|---|---|
|
Там в админке вроде отключается если тебе не надо HTML-кеш. Запись будет производится только в text.
|
| jcrush |
|
|---|---|
|
т.е. кеш не на всю базу? а только на часто открываемые страницы? как бы так по хорошему должно быть...
SEO блог: http://blog.stfw.ru/
|
| Trustmaster |
|
|---|---|
|
А чем оно мешает?
May the Source be with you!
|
| jcrush |
|
|---|---|
|
все равно какой смысл два раза в базе одно и тоже? хранить все в хтмл а парсить при редактировании добавлении.
SEO блог: http://blog.stfw.ru/
|
| Trustmaster |
|
|---|---|
|
А как ты собираешься редактировать ббкоды, если всё уже в HTML? Это ведь отнюдь не взаимно-однозначное преобразовние.
May the Source be with you!
|
| jcrush |
|
|---|---|
|
Что там неравнозначного? основные ббкоды можно в хтмл парсить и обратно, в DLE это прекрасно реализовано!
SEO блог: http://blog.stfw.ru/
|
| Sergeich |
|
|---|---|
|
А как разбор пользовательских тегов делать?
|
| Sergey |
|
|---|---|
|
Надо поставить парсер http://greg.chiaraquartet.net/archives/137-a-parser-generator-for-PHP-finally.html настроить таблицу тегов и получим скоростной парсер с исправлением ошибок - дело за малым: решиться.
www.cotonti.mobi
|
| Boss |
|
|---|---|
|
По-моему сейчас реализация самая правильная. Постоянно преобразовывать тест из BB в HTML и обратно глупо. Благо разработчики это понимают. Если бы было постоянно преобразование, то на котонти можно было бы смело ставить крест.
Конечно, база стала в два раза больше, но полезность кэша очевидна. ps: Статистика моей базы на котонти: БД SQL, число строк 244601 БД SQL, размер индекса (KB) 145 502.0 БД SQL, размер данных (KB) 111 872.1 БД SQL, общий размер (KB) 257 374.1 У кого-нибудь есть больше? |
| Sergeich |
|
|---|---|
|
Sergey, одна из фич котонти - возможность добавлять свои теги довольно простым путём, причём теги можно мутить довольно сложные и специфичные. Если внедрять парсер туда-сюда-обратно, то придётся, если я правильно понимаю, для каждого тега прописывать ещё и правила обратных преобразований не забывая о безопасности, плюс каждое преобразование - дополнительная нагрузка на сервер. Это, на мой взгляд, уже перебор. Я из двух зол выбираю меньшее - увеличение базы за счёт раздельного хранения html и bb, тем более дисковое пространство сейчас наименее затратная часть хостинга.
|
| Sergey |
|
|---|---|
|
Для того,чтобы понять как работают такие парсеры, достаточно познакомится с YACC и LEX в юниксе. Как это работает. Пишется грамматическое дерево разбора и отдельно пишется лексический анализатор все очень похоже на существующую базу ббкодов. В чем фишка парсера (YACC) он транслирует не текст страниц, он транслирует в дерево разбора сам разбор ббкодов. В результате получается компактная таблица переходов анализатора разбора - получается автомат. Затем, имеется очень короткая программа, которая просто читает текст в один проход!! и обнаружив ликсему типа [имя] или [/имя] генерирует код лексемы, программа, будем называть ее реализатор (она как правило крайне мала по размерам) в соответствии с таблицей разбора, назначает действие из другой таблицы (каждое правило грамматического разбора подразумевает действие). В чем прелесть такой системы. Прежде всего рекурсивность разбора, что дает делать совершенно немыслимые действия. А что вставляется в серверную часть? как раз не парсер, а вот этот реализатор с таблицей. Сам парсер запускают один раз, в случае изменения либо набора лексем, либо правил грамматического разбора. А какова скорость работы таких реализаторов, как правило совпадает со скоростью чтения файла, т.е чтения кэша. А возможности? Они беспредельны для дизайнеров типовых решений: например: вот как будет с рекурсивным разбором (придумано по ходу)
[b[red]] текст та-та - та и что- то написано красным что-то на выходе отмеченное красным будет еще и жирным. И так далее. Тут главное придумать смелые правила - рекурсия решает многое. www.cotonti.mobi
|
| jcrush |
|
|---|---|
|
не вижу очевидных плюсов такого парсера, в одном плюс в другом большой минус, а пользовательские ббкоды немногие юзают.
SEO блог: http://blog.stfw.ru/
|
| Sergey |
|
|---|---|
# jcrush : не вижу очевидных плюсов такого парсера, в одном плюс в другом большой минус, а пользовательские ббкоды немногие юзают.Без обид. А вы когда-нибудь писали для YACC и LEX? А вы знаете как устроены трансляторы, анализаторы и пр.? www.cotonti.mobi
|
