Forum Webscript.Ru
Программирование => PHP => Тема начата: D1g174LM4n14c от 07 Февраля 2004, 16:09:40
-
Хотелоь бы услышать мнение по этому поводу.
Пример следующий:
Есть поле в БД типа TEXT (max. 65535 bytes).
Есть скрипт добавляющий данные в БД.
Положим, на стороне клиента есть соответствующее ограничение на длину данных. Но скрипт при получении данных и перед записью их в БД применят, допустим, htmlspecialchars к этим данных. В результате может получиться так, что юзер отправит данных 65535 байт, а htmlspecialchars расширит их кол-во до какого-то большего размера. Предугадать или вычислить эту дельту для оставления запаса места в БД невозможно. Как тогда поступать?
Вариант: после htmlspecialshars вычислить длину данных и если она превышает лимит - выдать ошибку юзеру и данные не добавлять, пока проблема не будет решена.
Но если в PHP ф-ция strlen реализована также как в С++ - то это будет тормозно. Кто-то знает?
Ваши мнения?
-
1.
- доктор, когда я делаю так, мне больно!
- а вы не делайте так!
базе абсолютно все равно, что хранить
поэтому, исходя из принципа неприкосновенности данных, не надо просто данные портить.
2.
D1g174LM4n14c:
если в PHP ф-ция strlen реализована также как в С++ - то это будет тормозно
это еще что за глупость несусветная?
какая разница, как она организована?
чтоза голословный бред?
почему бы не попробовать выполнить стрлен и посмотреть - будет тормозно или нет?
-
1. Не надо портить...
А если просто необходимо htmlspecialchars применить к этим данным? Как в этом случае поступать?
2. В С++ strlen начиная с первого символа строки, проходит всю строку увеличивая указатель и таким образом считает колв-во символов. Поэтому эта ф-ция в С++ довольно "тяжелая".
А в PHP может быть strlen реализована по-другому. Например, строка на уровне кода интерпретатора уже описана с длиной или может длина вычисляется как разница между адресом последнего символа строки и первого... Куча вариантов. Вот тебе и разница...
-
Ничего тормозить не будет.
-
А если просто необходимо htmlspecialchars применить к этим данным
этого просто не может быть.
базе твои хтмлспециалчарс не нужны.
если они тебе нужны в другом месте - то и ДЕЛАЙ ИХ В ТОМ МЕСТЕ! это же очевидно.
делать надо там, где надо.
Поэтому эта ф-ция в С++ довольно "тяжелая".
ты в цифрах мерял, чудик?
твой вопрос напоминает вопрос человека, покупающего океанский лайнер и спрашивающего , дадут ли ему бесплатный коробок спичек.
Эта цифра настолько микроскопическая, что я вообще поражаюсь, как она тебе в голву могла придти.
то есть, я понимаю, конечно - слашал звон, да нихрена не понял, где он.
но голова-то тоже не только для того, чтобы в нее есть?
-
RomikChef:
если они тебе нужны в другом месте - то и ДЕЛАЙ ИХ В ТОМ МЕСТЕ! это же очевидно.
делать надо там, где надо.
а если я вывожу кучу новостей на страницу?
к каждой при каждой генерации странице применять htmlspecialchars??? зачем же так убивать время и ресурсы?
RomikChef:
Эта цифра настолько микроскопическая, что я вообще поражаюсь, как она тебе в голву могла придти.
а я про все думаю. даже про самое мелкое...
-
D1g174LM4n14c:
а я про все думаю. даже про самое мелкое...
есть такой персонаж в литературе - Плюшкин.
кому как, а у меня вызывает брезгливость.
но дело даже не в этом.
я готов поспорить на сто долларов, что в твоем коде есть места, в сто раз более неоптимальные, чем разница между тяжелым и легким алгоритмом strlen
ты не о том думаешь. точнее, у тебя просто у ма не хватает увидеть реальную проблему, и ты заморачиваешься совершенно бессмысленными.
не надо забивать голову глупостями
решать надо реальные проблемы ,а не высосанные... не знаю, откуда ты их там высасываешь. из пальца?
-
D1g174LM4n14c
А накой тебе новости с тектом содержащим "<,">" и прочим мусором.Лучше просто удалить все теги strip_tagsом.
Но хозяин барин,я просто хочу спросить
Роомик за что ты меня бросил ????? А.
-
RomikChef
Ты без грубости не можешь!
И запомни - я всегда знаю что я делаю!!!
Прощай.
-
D1g174LM4n14c:
Прощай.
надеюсь, это не пустые слова
-
Ромик, если следовать твоему совету "если они тебе нужны в другом месте - то и ДЕЛАЙ ИХ В ТОМ МЕСТЕ!", то при аплоаде картинок на сервер, картинки нужно ресайзить не во время аплоада, а при каждом выводе браузеру.
Конечно, в данной конкретной ситуации ты прав, но имхо эта грань слишком размыта, чтобы делать такие категорические заявления в столь грубой форме.
Ну а про strlen - тут и спорить не о чем, вроде всё уже сказали.
-
какие заявления?
где я писал резко про htmlspecialchars?
если же ты немного подумаешь, то изготовление превьюшек никак не противоречит принципу неприкосновенности данных.
-
если следовать моему совету, то для экономии ресурсов, если уж такая понядобится, надо, как и превьюшки, класть рядом.
а не заменять при вводе.
понимаешь разницу?
и превьюшки я бы генерил с удовольствием, если бы это не создавало нагрузку на сервер.
-
Если ты имеешь в виду генерацию превьюшки и сохранение её рядом с оригинальной фото, то я имел в виду немного другое. Я имел в виду ситуацию, когда сайту нужны только уменьшенные версии.
Только не говори про фотошоп :) Фотошоп - это, конечно, хорошо, но не все заказчики это понимают...
-
опять же - разница между бинарными данными и текстовыми.
как с хранением в базе.
не ббуквоедствуй.
ты здесь отстоишь принципиальную тождественность этих дпействий, а сто ламеров потом так делать будут на полном серьезе.
а резкость моя не от темы, а от
я всегда знаю что я делаю!!!
-
ОК, проехали.
Если кто ещё не понял предмет обсуждения (ну мало ли?), мы говорили о рациональности хранения и отображения данных.
В идеале, данные в базе данных должны храниться в чистом виде - без html-тегов, без html-энтайтисов (как на русский перевести нормально, не подскажите?), без всякого рода прочих модификаций типа [p]wordwrap[/p]. А обрабатывать данные нужно непосредственно при их запросе и отображении.
Но есть и исключения: например, ресайзинг изображений нужно делать во время аплоада этого изображения, а не во время его отображения.
Чтобы определить, как поступить в той или иной ситуации, лучше лишний раз провести тесты на производительность, оценить расходы ресурсов на решение вашей конкретной задачи, учесть пиковую загруженность сервера и только после этого выбрать один из двух вариантов.
-
FreeSpace:
В идеале, данные в базе данных должны храниться в чистом виде
совершенно неправильное утверждение.
вообще ты не в те степь ушел.
картинку, если она не нужна в большом виде - бессмысленно хранить.
в этом смысле, если содержимое текстового поля совершенно точно не будет редактироваться, то его тоже можно
-
Рома, я же так и написал:
Но есть и исключения: например, ресайзинг изображений нужно делать во время аплоада этого изображения, а не во время его отображения.
Я имел в виду ресайзить на этапе аплоада и хранить уже ресайзнутую картинку.
Если есть 100% уверенность в том, что данные не нужно будет изменять, то да, ты прав, можно один раз их обработать и хранить в БД обработанную версию. Но на практике такое бывает очень редко, имхо.
-
D1g174LM4n14c:
а если я вывожу кучу новостей на страницу?
к каждой при каждой генерации странице применять htmlspecialchars???
D1g174LM4n14c:
а я про все думаю. даже про самое мелкое...
тогда как ты будешь делать редактирование существующих новостей ? Или предложишь админу редактировать новости с кучей & nbsp; и т.д.
Я уверен, что htmlspecialchars не будет самым узким местом в твоем скрипте (в отличие от примера с генерированием превьюшек ).
-
FreeSpace
я понял.
ты путаешь
ВО!
дошло.
хранить надо именно в том виде, который нужен.
ты же делаешь тексту трим при получении его из формы?
это тебе твой первичный ресайз, понимаешь?
-
Да, с таким аргументом спорить не возьмусь :)
Но всё же согласись, эта грань весьма размыта.
Ведь если на тысячу запросов на просмотр будет один запрос на редактирование, то проще сделать [p]html_entity_decode[/p] один раз, чем [p]htmlspecialchars[/p] тысячу...
Хотя, ты меня убедил, ты прав.
-
а при чем здесь ентити?
это же принцип.
в от в этом форуме бб код а не хтмл.
и редактирование нужно часто.
если так уж парит вопрос производительности, то решаем стандартно - через объем, храним исходник и результат.
-
редактирование - не единственная задача.
есть еще вывод в шаблонах, со стрип тагсом, есть текст в принтер версии и так далее.
-
Да я не спорю ведь - есть куча разных задач и столько же разных решений.
Как ты сказал, можно хранить и исходник, и результат - тогда у нас будет кэширование. Вроде бы всё хорошо, но объем БД примерно в два раза больше. Так что тут нужно смотреть, что дороже - объем БД или процессорное время. В третьем вбуллетне (если уже мы заговорили о форумах) поступили умнее и скомбинировали эти два подхода: там можно задать время кэширования отпарсенных постов (в которых ббкод уже обработан и коротые хранятся в базе данных в виде хтмл), или при желании вообще его отключить.
Про стрип тагс и версию для печати - опять же, решение нужно искать под конкретную задачу. Я лишь рассмотрел самые общие варианты с их плюсами и минусами.