Как вы фильтруете данные — до сохранения в базу или при выводе?

Question

[Meliborn]

Или в обоих случаях?

Answer 1

[EugeneOZ]

Что значит «фильтровать»? Если защита от SQL-инъекций — то, безусловно, фильтровать нужно до записи. Но фильтровать не вырезанием и экранированием, а с помощью placeholders в PDO. Подробнее: habrahabr.ru/post/148701/
При выводе нужно эскейпить то, что может исполнится внутри HTML, тут уже поможет обычная htmlspecialchars() или использование нормального шаблонизатора (Twig, например).

Answer 2

[Михаил Лялин]

без фильтра на входе непредсказуемый рост объёма базы и сложности поиска в ней

Answer 3

[Анатолий]

И то и то правильно, если вам нужно обрабатывать в дальнейшем данные неочищеные, то логично что хранить вы их будете сырыми и очищать лишь при выводе. А если вам нужно хранить лишь определенный формат (нельзя тэги например) то очищать перед записью все лишнее не помешает, мало ли где показываться будут данные.
А вот при выводе нужно данные фильтровать всегда. Это самая частая ошибка =)
В базе храните что угодно, при выводе же что угодно показывать нельзя.

Answer 4

[eaa]

Например, нам надо считать статистику. Соответственно каждую секунду мы пишем некий объем информации. Имеем огромную базу, но и можно делать с ней все. что угодно. При выводе фильтрация и всякие арифметические операции — суммирование по неделе, месяцу и т.п.

Далее, если данных очень много — выборки начинают тормозить. А посему надо базу как-то подчищать, по крайней мере с посекундными данными. Это можно делать при вставке — например старые перекладывать куда-то, суммировать и писать уже суммы и т.п. — это уже обработка при сохранении.

Еще по-хорошему надо просто периодически по такой базе проходиться и ее оптимизировать — то же суммирование, генерирование отчетов — чтоб каждый раз не перелопачивать всю базу — такой вот периодический этап фильтрации-оптимизации.

Answer 5

[Angerslave]

Мда, не очень понятно что подразумеваете под фильтрацией? Не прошла форма валидацию — ответили пользователю отказом и не записали ничего, прошла — записали всё как есть. На выводе эскейпим. Это, конечно, в общем случае, в разных задачах могут быть разные вариации.

Comments

[Meliborn]

В том то и дело, почему именно при выводе эскейпить? Если куча запросов на страницу, это может сказываться на скорости. Операция одна и та же, не проще ли один раз перед сохранением заескейпить, а потом тянуть просто переменную без обработки? Это если в двух словах.

[EugeneOZ]

Потому что в базе данных должны лежать данные, а не представление. Где-то их нужно эксейпить — это уже трудности того представления. В другом представлении их ненужно будет эскейпить.
Не вздумайте никогда хранить в БД готовые страницы.

[EugeneOZ]

И экономия на htmlspecialchars это смешно. Экономьте на запросах к БД, кэшируйте их и используйте профайлер, чтобы найти реальные слабые места, а не htmlspecialchars.

[Meliborn]

Во многих php-framework'ах (kohana, yii и т.д.) у моделей есть метод filters, который фильтрует данные непосредственно перед занесением в базу. Судя по документациям и мануалам, почти все пихают туда тот же htmlspecialchars, trim, кастомные регулярные выражения.

[EugeneOZ]

Процитируйте, пожалуйста, где в документациях есть такое.
Я Вам объяснил, почему не нужно этого делать. Есть контр-аргументы?

[Meliborn]

Вы наверное думаете что я сторонник фильтрации перед сохранением. Нет нет, я хочу разобраться, почему многие так делают. Плюсы вашего способа я понял, хотелось бы услышать другую сторону.

[Angerslave]

На одном очень старом форуме была старая версия phpBB, которая сохраняла уже заэскейпенные данные в базу. Затем, версию phpBB обновили, в результате старые посты похерились — они содержали готовый HTML, из которого извлечь BB-code было нереально.
В общем, это проще только поначалу, экономия обычно мизерная, лучше кэшировать сразу страницу целиком, чем писать в базу эскейпнутые данные.
Сам может пару раз за всю карьеру таким занимался, но затем решил этого не делать, да и вообще единственные «фильтры», которые я применяю к данным — конвертация форматов (дата в таймстемп — при извлечении обратно, массив в строку — при извлечении обратно и т.д.)
В общем, если при фильтрации исходные данные можно восстановить, то в принципе это ещё ничего, не так плохо, как необратимая фильтрация.

[EugeneOZ]

Meliborn, я же ответил уже — данные не должны зависеть от представления. Подумайте, что будет, если эти данные Вы захотите вывести не на HTML-странице, а в Excel-листе или в виде текстового файла. Как будут там смотреться эти %20%E5?
Не смешивайте отображение и данные. Ни в коде, ни в базе. Это очень легко допустить и это превращается в большую боль позже.

[Meliborn]

Я собственно так и делаю сейчас. Вопрос возни из-за спора с коллегами.

Answer 6

[ohmytribe]

При добавлении в базу — фильтруем. При выводе — форматируем.