@quiqqe

Как правильно хранить контент поста?

Суть следующая - необходимо хранить контент поста в бд (используется laravel)
Посты будут создаваться в админ панели через динамичный генератор. Необходимо учитывать порядок содержимого (заголовки, оглавление, изображение и т.д), так как нек-ые из элементов могут отсутствовать или иметь разный порядок.
Хранить html код в столбце поста кажется нецелесообразным по ряду причин:
  • Лишняя трата памяти на хранение html тегов
  • Уменьшение производительности (?)
  • Стили/компоненты могут изменяться, а код останется прежним

Придумано два варианта решения:
  • Использовать собственные минифицированные теги, благодаря которым определенный парсер будет воссоздавать нужные блоки с помощью компонентов (возможно динамичесих)
  • Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id), используя отношения к родительскому посту, соответственно сохранится структура и рендериться пост будет через соответствующие компоненты в нужном порядке (однако как будет именно рендериться в шаблоне поста пока неизвестно)

Вопрос следующий: насколько второй подход имеет место быть, и если нет, то какие есть best practices для подобных случаев (как это реализуется в крупных проектах?)
  • Вопрос задан
  • 232 просмотра
Пригласить эксперта
Ответы на вопрос 2
ThunderCat
@ThunderCat Куратор тега Веб-разработка
{PHP, MySql, HTML, JS, CSS} developer
Хранить html код в столбце поста кажется нецелесообразным по ряду причин:
Угу, ага...

Лишняя трата памяти на хранение html тегов
Ого, а лишние это сколько? Экономия на байтах чаще всего приводит к тратам на вычислительные мощности. Некоторые расчеты чуть ниже.
Уменьшение производительности (?)
Производительности чего?

Стили/компоненты могут изменяться, а код останется прежним
Стили как раз и нужны для того, чтобы легко конфигурировать визуал, не привязываясь к коду. Код может быть каким угодно, но стилизация через теги пока что лучший вариант, который придумали разработчики.

Использовать собственные минифицированные теги, благодаря которым определенный парсер будет воссоздавать нужные блоки с помощью компонентов (возможно динамичесих)
Ага, переизобретаем BBCode, найс... Для понимания проблемы - такие коды придуманы для форумов, с целью ограничить использование хтмл в пользовательском вводе. При этом подходе он худо-бедно оправдан, хотя и требует постобработки при каждом выводе, а это использование регулярок, что как бы совсем не бесплатно. В вашем же случае, источник текста более-менее доверенный, и ограничение в тегах больше мешает чем помогает.
Что касается экономии на "минифицированных" тегах, ну допустим сэкономите вы 100 байт на тегах, то есть на 1000 постов экономия будет.... ТА-ДАААМ! 0,1 мегабайта! А если экономия 1000 байт на пост, то целый МЕГАБАЙТ можно сэкономить! Похвальная рачительность.

Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id), используя отношения к родительскому посту, соответственно сохранится структура и рендериться пост будет через соответствующие компоненты в нужном порядке (однако как будет именно рендериться в шаблоне поста пока неизвестно)
Базовые элементы и так должны храниться отдельно, другой вопрос почему они у вас рендерятся в одном порядке, а в другом месте в другом порядке? Заголовок, короткое описание, текст, главное изображение - отдельные поля, оглавление по сути часть текста, зачем его выносить отдельно - загадка, это же такой же текст, котрый автор волен располагать . Вариант с внешней таблицей по сути приводит нас к выносу части данных в EAV(отличный пример универсализации в ущерб производительности), что как раз будет серьезно напрягать выборки бд, если понадобится делать какие-либо поисково-выборочные манипуляции по этим данным.
Ответ написан
mayton2019
@mayton2019
Bigdata Engineer
Использовать собственные минифицированные теги, благодаря которым определенный парсер будет воссоздавать нужные блоки с помощью компонентов (возможно динамичесих)

20 лет назад этот вопрос был полнонстью решен с помощью технологий XML/XSLT/XPath.
Языки C#/dotNet, Java поддерживают этот стек. И много других языков и библиотек.

Потом еще создавали более простые вещи. Шаблонизаторы. Velocity, FreeMarker. Они немножко
переворачивают постановку. Но их тоже можно рассмотреть.

Хранить html код в столбце поста кажется нецелесообразным.

С точки зрения суммарной стоимости владения (TCO) база данных всегда будет дороже
чем файловая система. А самым дешевым будут хранилища типа Amazon S3, MS Blob, G-Drive.
Ну если пересчитать удельно сколько стоит гигабайт.

Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id),
Тут - непонятно. Но есть такое эвристическое правило дизайна
хороших NoSQL систем. Все данные для запроса должны лежать физически рядышком
и не требовать дополнительных действий
. В идеале - для отдачи поста вы должны сделать
один единсвтвенный SELECT без joins и без подзапросов и агрегаций и без CONNECT-BY.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы