Решение проблемы урезания данных!

[FreeSpace]

ОК, проехали.
Если кто ещё не понял предмет обсуждения (ну мало ли?), мы говорили о рациональности хранения и отображения данных.
В идеале, данные в базе данных должны храниться в чистом виде - без html-тегов, без html-энтайтисов (как на русский перевести нормально, не подскажите?), без всякого рода прочих модификаций типа [p]wordwrap[/p]. А обрабатывать данные нужно непосредственно при их запросе и отображении.
Но есть и исключения: например, ресайзинг изображений нужно делать во время аплоада этого изображения, а не во время его отображения.
Чтобы определить, как поступить в той или иной ситуации, лучше лишний раз провести тесты на производительность, оценить расходы ресурсов на решение вашей конкретной задачи, учесть пиковую загруженность сервера и только после этого выбрать один из двух вариантов.

[Меняздесьдавнонет]

FreeSpace:
В идеале, данные в базе данных должны храниться в чистом виде

совершенно неправильное утверждение.

вообще ты не в те степь ушел.

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

[FreeSpace]

Рома, я же так и написал:

Но есть и исключения: например, ресайзинг изображений нужно делать во время аплоада этого изображения, а не во время его отображения.

Я имел в виду ресайзить на этапе аплоада и хранить уже ресайзнутую картинку.

Если есть 100% уверенность в том, что данные не нужно будет изменять, то да, ты прав, можно один раз их обработать и хранить в БД обработанную версию. Но на практике такое бывает очень редко, имхо.

[Макс]

D1g174LM4n14c:
а если я вывожу кучу новостей на страницу?
к каждой при каждой генерации странице применять htmlspecialchars???

D1g174LM4n14c:
а я про все думаю. даже про самое мелкое...

тогда как ты будешь делать редактирование существующих новостей ? Или предложишь админу редактировать новости с кучей & nbsp; и т.д.

Я уверен, что htmlspecialchars не будет самым узким местом в твоем скрипте (в отличие от примера с генерированием превьюшек ).

[Меняздесьдавнонет]

FreeSpace
я понял.
ты путаешь
ВО!
дошло.
хранить надо именно в том виде, который нужен.
ты же делаешь тексту трим при получении его из формы?
это тебе твой первичный ресайз, понимаешь?

[FreeSpace]

Да, с таким аргументом спорить не возьмусь
Но всё же согласись, эта грань весьма размыта.
Ведь если на тысячу запросов на просмотр будет один запрос на редактирование, то проще сделать [p]html_entity_decode[/p] один раз, чем [p]htmlspecialchars[/p] тысячу...
Хотя, ты меня убедил, ты прав.

[Меняздесьдавнонет]

а при чем здесь ентити?
это же принцип.
в от в этом форуме бб код а не хтмл.
и редактирование нужно часто.

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

[Меняздесьдавнонет]

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

[FreeSpace]

Да я не спорю ведь - есть куча разных задач и столько же разных решений.
Как ты сказал, можно хранить и исходник, и результат - тогда у нас будет кэширование. Вроде бы всё хорошо, но объем БД примерно в два раза больше. Так что тут нужно смотреть, что дороже - объем БД или процессорное время. В третьем вбуллетне (если уже мы заговорили о форумах) поступили умнее и скомбинировали эти два подхода: там можно задать время кэширования отпарсенных постов (в которых ббкод уже обработан и коротые хранятся в базе данных в виде хтмл), или при желании вообще его отключить.
Про стрип тагс и версию для печати - опять же, решение нужно искать под конкретную задачу. Я лишь рассмотрел самые общие варианты с их плюсами и минусами.