Как организовано хранение статей сайта в бд?

Question

[Arbitr]

Допустим есть статья, в которой помимо текста хранятся ссылки, картинки и т.д.. Каким образом организовано хранение данной статьи в бд? Точно знаю, что популярные CMS хранят в базе информацию со всеми тегами, но такой подход обычно ругают, да и он сам не выглядит серьезно. Какие еще есть варианты хранения "сложного" контента?

Comments

[imdeveloper]

Нормальный подход. Это же просто текст для БД или вы думаете , что базы данных разбирают теги на части или как-то по особому хранят их?
P.s если ссылка, то это ссылка , если картинка , то это путь к картинке на сервере, а не сам файл

[Павел]

А где ругают, можно поинтересоваться? Если людям не нравится подход, они обычно знают альтернативу. Действительно интересно, каким образом контент статьи можно разделять, а потом собирать все в кучу обратно, учитывая, что с фронта прилетает просто строка из WYSIWYG редактора.

[Сергей delphinpro]

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

[hckn]

Я храню теги отдельно, а в самой статье указываю id

[Arbitr]

imdeveloper, А если в статье много картинок, при этом они идут по ходу текста, а не одна за другой, как тогда быть? Хранить тег Img прямо в тексте статьи?

[Arbitr]

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

[Павел]

Arbitr, почему? и чем тэги отличаются от обычного текста, с точки зрения БД? Отвечу - ничем, это такие же символы как и остальные. И да, если много картинок подряд, то так и храните разметку всю в БД. Если это реально просто контент записи в перемешку с остальным. А если вам нужна какая-нибудь галерея, что бы её можно было вытащить отдельно от контента, то это уже другой вопрос, тогда нужно отдельное поле в таблице делать и хранить эти ссылки/id картинок отдельно.

[Arbitr]

Всем спасибо за ответы.

[alex-1917]

во ВСЕХ CMS контент хранится именно кучей. Это как минимум быстрее при ВЫВОДЕ, поняли намек?))) А ваша задумка - делить - приводит ПРИ ВЫВОДЕ к обязательности сбора всех этих кусочков - как думаете, что быстрее?

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

по всей планете плачут котята...))))

Это вы еще не знаете, что, например, тот же ModX вообще хранит весь шаблон с этими вашими тегами также в БД. Вы будете в ужасе)))

[imdeveloper]

Arbitr, что-то вы ничего не понимаете "батюшка". Т.е что бы они шли одна за одной вы не используете html+css,а что-то о чем мы не знаем?

[imdeveloper]

Arbitr, ты выводишь html на фронт, остальное дело за CSS и JS если нужно. Вся структура ,в том числе и img's уже должны быть сформированы на уровне сохранения в БД

Answer 1

[Ambrosian]

Arbitr,

А если в статье много картинок, при этом они идут по ходу текста, а не одна за другой, как тогда быть? Хранить тег Img прямо в тексте статьи?

почему нет?
причем, не обязательно прямо-таки именно чистый тег <IMG>.
а вполне можно хранить специальным тегом типа ![GitHub Logo](/images/logo.png) причем со ссылкой просто на идентификатор картинки, а конкретные пути к файлу будут подставляться при формировании страницы для посетителя.
это был пример из Markdown

Все зависит от задач

Если текст более никак не будет изменяться, то чего мудрить-то? проще (производительнее) будет хранить сразу конечный тег в тексте.

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

Почему теги нельзя хранить в текстах - это другая причина. Нельзя хранить произвольные теги в текстах. А жестко ограниченный набор тегов (например IMG, STRONG и т.п.) с запрещенными стилями - отчего нет?

Arbitr,

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

Речь о том, что теги могут влиять на форматирование.
Но если набор тегов ограниченный и они проходят контроль и очистку перед помещением в БД, то - можно.

P.S.:
Строго говоря, хранить имеет смысл не чистые теги HTML, а намеки на них. Например, текст:

Это некий текст. А вот тут картинка #img#id0234#

По сути это тоже тег. Но вы его преобразуете в <IMG> по определенным правилам. Сегодня у вас картинка лежит в http://example.com/images/id0234.jpeg, а завтра вы решили поместить картинки на отдельный сервер в облако и адрес будет https://images.example.com/id0234.jpeg

Answer 2

[xmoonlight]

Мыслите правильно!
Однозначно, весь текст статьи/публикации/материала нужно разбивать на модули:
1. Заголовки статьи: все уровни ("дерево" заголовков или, проще говоря, содержание)
2. Теги (1..N)
3. Параграф (1..N)
4. Изображение (1...N)
5. Видео (1..N)
6. Исходный код (1..N)
7. Спойлер (1..N)
8. Внутренний iframe (1..N)
9. Внешний виджет: ролик youtube, codepen.io, jsfiddle.com и т.д. (1...N)
10. Комментарии (1..N)
11. Линки (1..N)
и т.д.

И саму структуру статьи ("древовидный каракас"): где и что должно располагаться, что и куда должно быть вложено, и в каком порядке следовать друг за другом (разметка вместе с ID-шниками ресурсов).

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

И про правильное хранение текстовых данных (сегментацию): здесь

Comments

[Yan-s]

xmoonlight не могли бы вы привести примеры реализации такого подхода?

[xmoonlight]

Yan-s, Поясните, что именно Вы желаете увидеть?

[Yan-s]

xmoonlight, ну например CMS где реализован такой подход. Или подобного рода система.

[xmoonlight]

Yan-s, я не встречал в паблике.

[saetoniux]

Yan-s, например, Drupal. В множестве проектов используется подобный подход — материал разбивается на уникальные и повторяющиеся поля. Т.е. в админке отдельно основной текст, отдельно анонс, отдельно картинка, отдельно видео, отдельно другие специализированные контентные блоки, состоящие из набора полей (например, модули paragraphs или bricks). Затем всё это собирается в шаблоне с необходимой вёрсткой (просто подряд или как-то замудрённо).

[Yan-s]

saetoniux, то о чем говорится в ответе я понял как разбор документа на DOM элементы и хранение этого всего в виде самостоятельных объектов (отдельные записи, а не поля одной), так же отдельно хранится дерево описывающее как это всё собрать в одну публикацию.

[xmoonlight]

Yan-s, всё верно, только не факт, что именно разбор DOM. Может быть и усовершенствованный markdown-синтаксис какой-нибудь. Всё зависит от того, в каком виде новая публикация приходит в обработку для постинга.

Answer 3

[Katzuhiro_Akira]

Если хотите узнать структуру хранения, то почему нельзя вскрыть сам движок?
У вордпресс, например хранения, вроде, вообще имеет прямые ссылки и идентификаторы внутри базы, которая состоит из 5-6 таблиц(по сути это одна таблица, которая раздроблема).
Каждый отдельный элемент хранится отдельно(текст1,текст2,картинка).

Для понимания рекомендую разобрать сами базы движков. У вордпресса это таблицы, которые в списке находятся рядом с _posts. Если проявить немного логики, то понять станет очень просто.

Comments

[Mr__Twister]

Раз уж я залез в базу Вордпресса, то дополню иллюстрацией. Из неё видно, что есть поле post_content типа bigint и в ней содержится чистый HTML: