Секционное хранение статьи в базе данных — проблемы производительности?
Создаю блог и столкнулся с вопросом хранения публикаций.
Публикации разделены на секции, фигуры (картинки с подписями, видео, аудио), списки, ... И каждая из секций имеет заголовок, а возле этого заголовка нужно выводить статический системный код (добавление секции в закладки).
Я выбирал между 3 вариантами: хранение html кода прямо в строке записи таблицы article - разбор по regex и разбор по DOMDocument; хранение статьи в отдельных таблицах: section FK article, paragraph FK section, figure FK section.
Я выбрал последний вариант.
Соответственно, я могу как угодно оформлять секции (на данный момент выбрал тег section), что угодно добавлять возле заголовков, добавлять кнопку "читать далее" к последнему абзацу и так далее. То-есть, в базе содержится только важная читабельная информация, а все форматирование возлагается на сторону PHP.
1. Насколько ущербная в плане производительности выборка по данной архитектуре?
2. Что лучше: выборка сначала секций к статье, потом абзацев и фигур к секции отдельными запросами или все одним запросом с последующим FULL OUTER JOIN и группировкой по позиции в статье?
непонятно что у вас не группируется, сейчас подойдут экстрасенсы. Будем думать что у вас за запрос к базе идет, и что значит колонка дублируется. Дайте нам минут 10 и мы вам поможем
Из того "что получить в итоге" видно, что обе таблицы можно элементарно слить в 1, но с 3 столбцами, тогда твоя проблема решается поумолчанию+экономия памяти, места на диске и производительность (т.к. записи будут "рядом")
Средний
