Соцопрос. В каком виде лучше хранить данные в БД.

Вопрос прост.
Раньше в PHP<5.3 активно использовался сырой MySQL и естественно, для пущей безопасности люди старались максимально обезопасить себя от SQL-инъекций и хранили данные в БД в виде уже обработанных строк как минимум - обычным htmlspecialchars() или чего-то серьезней. А переносы строк - в подготовленном виде <br /> (для простоты вывода информации, просто вывел строку на экран - и все красиво).

С появлением PDO и подготовленных запросов начался холивар, как лучше и проще хранить данные.
- Первые говорят, что лучше хранить в сыром виде, т.к. на безопасность это уже не влияет, но места занимает меньше.
- Вторые настаивают на том, что на место это особо не влияет, но удобство для вывода на экран - на лицо. И инъекции исключает на миллион% даже при дырах в PDO, не зависящих от тебя. И не надо заморачиваться с отображением переносов строк.

Как вы поступаете? Я раньше был приверженец 1-го способа (экранировать данные прямо в БД), но решив перейти на 2-й (без экранирования данных в БД) и перечитав кучу холиваров, вроде решил остаться на первом.

Посоветуйте что-то и обоснуйте в комментах свой голос. Сенкс.

Хранить в сыром виде, фильтровать при выводе.
Собственно и во времена 5.3 ничего принципиально не отличалось т.к. есть специальные функции для экранирования символов (и защиты от sql инъекций соответственно).
Почему нужно фильтровать именно на выходе? Потому, фильтр на выходе ты сможешь доработать и например исправить какие-то косяки или как-то по особому обработать что-то не заставляя пользователей переписывать все свои сообщения.
Да, обработка при выводе в некоторых случаях может быть затратной, но это уже отдельная история из которой тоже есть выход )

Дмитрий, сейчас в современных фреймворках по умолчанию в бд хранится в сыром виде, фильтруется при выводе, в laravel и symfony например

А если в будущем тебе понадобится вывести данные из базы не в html-страницу, а в json/xml/txt формат и т.д., например для api, а у тебя там всё закодировано через htmlspecialchars()

Добавлено через 08:13 сек.
И еще, если большой текст из базы у тебя будет разбиваться на несколько частей, то есть вероятность что какой-нибудь тег например "<" разобьется на две части "&" и "lt;" и... отобразится как есть, текстом

Добавлено через 08:56 сек.
Да еще и с поиском по базе будут нюансы

Эх, надо тоже по возможности переделать, чтобы хранилось правильно

Вантуз-мен, что переделать?)

Автор наверно делает по старинке, типа

function safe_int($str) {
  $str = htmlspecialchars($str); # как же без него
  $str = htmlentities($str); # и еще так на всякий случай
  $str = mysql_escape_string($str);
  $str = mysql_real_escape_string($str); # хоть одна, да сработает)
  $str = addslashes($str); # экранируем кавычки
  $str = stripslashes($str); # и... убираем слэши)
  $str = serialize($str); # да-да,...
  $str = unserialize($str); # ...я и такое видел)
  $str = abs($str); # ???
  $str = intval($str); # ах да, это же функция для чисел)
  $str = trim($str); # вот теперь можно писать в базу)
}

Подобная функция была musthave в то время, без нее не обходился ни один движок

erasier, в роторе некоторые символы экранируются перед записью в бд, это еще со времен wap-motora осталось, вот нужно заменить все в бд назад и проверить везде ли фильтруется на вывод

Еще видел в некоторых скриптах перед добавлением в базу из строк регуляркой вырезаются ключевые слова типа "select", "update", "script", "xss" и т.д.

Добавлено через 02:42 сек.
Еще тут во втором посте писали про "затратность" экранирования при выводе, ну это конечно бред полнейший, по сравнению с нагрузкой от запросов к бд, экранирование хтмл - это так, семечки

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

Нагрузка от запросов к БД и затратность постобработки полученных из БД данных... Что-то я не очень логическую цепочку улавливаю. Ты как-то научился получать данные из БД не выполняя запросы?
З.Ы. попробуй обезопасить голый html, который получен из БД и потом расскажи какие у тебя получились результаты. Под "обезопасить голый html" я не имею в виду просто прогнать его через htmlcpecialchars. Имею в виду оставить белый список классов, атрибутов, тегов.
Ну если конечно в твоем понимании обработка на выводе это только экранирование html, ну штош, понятно, вопросов нет.