Правильная ли практика хранить в базе данных html code?

общая информация

Код в базе хранят если это конструктор, шаблон или редактор, хотя для продвинутых редакторов код трансформируется в json или подобные структуры

Если пользователям нужно предоставить возможность форматировать вывод, то сохранять код в базе самое простое решение.

HTML-код для базы - это просто строка, никакой опасности нет, при правильном сохранении/санитизации данных.

Опасность - отображение этого кода на странице в браузере пользователя.

рекомендации

Если вы создаете закрытую систему, для доверенных пользователей, то проблем нет.

Если это открытая система, то однозначно нужно ограничить пользователей базовыми возможностями. Без модерации всё равно не обойтись.

размышления

Не все задачи, связанные с форматированием контента можно решить через организацию UI. Встроенные HTML-редакторы решают множество проблем для копирайтеров и контент-менеджеров, позволяют создавать и редактировать шаблоны в CMS. Современная тенденция - это ограничение набора функций с сохранением возможности форматирования.

В базе нужно хранить данные.
Если ваши данные - это html-код, храните его, в чём проблема?

Основные проблемы хранения html для отображения его в браузере:

• доверие
  Вам придётся доверять пользователям, создающим этот контент. Они без проблем могут внедрить уязвимости в свой html... Если это неопределённый круг лиц — с этим придётся что-то делать.

• статичность
  Эти куски кода верстались под старую версию сайта. Вы обновили дизайн — нужно перепроверять, что все кусочки из базы будут адекватно смотреться в новом дизайне

• производительность
  Статические куски темплейтов лучше таки отдавать с диска напрямую, nginx умеет это делать гораздо шустрее, чем связка php+mysql, а браузеры замечательно их кешируют.

User-generated контент в любом случае стоит как-то ограничивать, современные шаблонизаторы умеют закрывать большинство известных уязвимостей. Используйте один из них и добавьте «Предпросмотр».

Также, вероятно, стоит разбить контент на смысловые составляющие (заголовок, тело и т.п.), чтобы сохранять непосредственно контент(форматирующие шаблоны вроде Markdown/BBcode подойдут) и внедрять уже этот контент в текущий дизайн.

Если же это просто шаблоны для client-side GUI компонентов - перенесите их в document_root. webpack вообще умеет компилировать их в js

Прямо сейчас я набираю этот ответ, и мне достаточно выразительных средств без html. И предпросмотр на месте. Попробуйте пристальнее изучить механизм ввода вопросов/ответов. Если бы stackoverflow хранили бы html, - старые вопросы/ответы сегодня бы выглядели совсем не так, как новые..