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

Печать / RSS

В каком виде хранить данные в PDO?

В сыром виде, и можно не париться. (Голосов: 4)
80%
В экранированном обязательно. (Голосов: 1)
20%
В любом виде, это не влияет на производительность. (Голосов: 0)
0%
Ты дебил или чо? Покури мануалы. Сейчас обосную. (Голосов: 0)
0%
Всего проголосовало: 5
+1
1. Дмитрий 15.06.2020 / 01:32
Малиновые штаны
Вопрос прост.
Раньше в PHP<5.3 активно использовался сырой MySQL и естественно, для пущей безопасности люди старались максимально обезопасить себя от SQL-инъекций и хранили данные в БД в виде уже обработанных строк как минимум - обычным htmlspecialchars() или чего-то серьезней. А переносы строк - в подготовленном виде <br /> (для простоты вывода информации, просто вывел строку на экран - и все красиво).

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

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

Посоветуйте что-то и обоснуйте в комментах свой голос. Сенкс.
+1
2. Максим 15.06.2020 / 02:08
Чатланин
Хранить в сыром виде, фильтровать при выводе.
Собственно и во времена 5.3 ничего принципиально не отличалось т.к. есть специальные функции для экранирования символов (и защиты от sql инъекций соответственно).
Почему нужно фильтровать именно на выходе? Потому, фильтр на выходе ты сможешь доработать и например исправить какие-то косяки или как-то по особому обработать что-то не заставляя пользователей переписывать все свои сообщения.
Да, обработка при выводе в некоторых случаях может быть затратной, но это уже отдельная история из которой тоже есть выход )
+1
3. Вантуз-мен 15.06.2020 / 02:19
Господин ПЖ
@DimaVip, сейчас в современных фреймворках по умолчанию в бд хранится в сыром виде, фильтруется при выводе, в laravel и symfony например
+1
4. erasier 15.06.2020 / 08:41
Пацак
А если в будущем тебе понадобится вывести данные из базы не в html-страницу, а в json/xml/txt формат и т.д., например для api, а у тебя там всё закодировано через htmlspecialchars() ).gif

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

Добавлено через 08:56 сек.
Да еще и с поиском по базе будут нюансы ).gif
0
5. Вантуз-мен 15.06.2020 / 10:10
Господин ПЖ
Эх, надо тоже по возможности переделать, чтобы хранилось правильно
0
6. erasier 15.06.2020 / 11:44
Пацак
@Vantuz, что переделать?)
0
7. erasier 15.06.2020 / 12:01
Пацак
Автор наверно делает по старинке, типа
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 в то время, без нее не обходился ни один движок ).gif
Изменил: erasier (15.06.2020 / 12:02)
0
8. Вантуз-мен 15.06.2020 / 14:14
Господин ПЖ
@erasier, в роторе некоторые символы экранируются перед записью в бд, это еще со времен wap-motora осталось, вот нужно заменить все в бд назад и проверить везде ли фильтруется на вывод
+1
9. erasier 15.06.2020 / 19:45
Пацак
Еще видел в некоторых скриптах перед добавлением в базу из строк регуляркой вырезаются ключевые слова типа "select", "update", "script", "xss" и т.д. D.gif

Добавлено через 02:42 сек.
Еще тут во втором посте писали про "затратность" экранирования при выводе, ну это конечно бред полнейший, по сравнению с нагрузкой от запросов к бд, экранирование хтмл - это так, семечки ).gif
0
10. Максим 15.06.2020 / 20:11
Чатланин
Еще тут во втором посте писали про "затратность" экранирования при выводе, ну это конечно бред полнейший, по сравнению с нагрузкой от запросов к бд, экранирование хтмл - это так, семечки@erasier

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