Секционное хранение статьи в базе данных

я так понимаю структура таблиц будет такая: таблица статья, таблица секции, таблица связей вроде

Article

[id, title]

Section

[id, title, body]

ArticleSection

[article_id, section_id]

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

---------- Добавлено 22.10.2014 в 02:54 ----------

Вы уверены, что секции надо делить на три разные таблицы? Вероятно там сильно много общего наверняка можно обойтись одной. Тогда и проблем с выборкой из трех таблиц не будет, а архитектура предполагающая FULL OUTER JOIN имхо заслуживает того, чтобы ее пересмотрели.

iqmaker, почти:

Таблица article (id, uri (адрес статьи), title (название статьи = h1), date-modified, owner (автор)).

- Таблица section (id, article (внешний ключ к article.id) title (название секции = h2), position (позиция объекта относительно начала статьи)).

-- Таблица paragraph, figure, ... child (объекты секции) - поля индивидуальные, например, для figure это figcaption и ссылка на объект, но у всех есть внешний ключ к section.id и position.

Просто у меня фрустрация после работы с WordPress, DLE. Кругом для форматирования текста используют регулярные выражения, а статью сохраняют в обычном HTML коде.

Но снова таки, HTML это служебные данные и должно создавать множество проблем, начиная от увеличения потребления ОЗУ (я думаю), заканчивая фиктивными результатами поиска скажем по LIKE '%<p>%' (найдет все абзацы, вместо того, чтобы найти все статьи в которых рассказывается по значении тега p).

О regex говорить не стоит, он просто не предназначен для работы с динамическим HTML контентом. В любом случае, стабильное во всех случаях выражение будет явно менее продуктивнее DOMDocument.

---------- Добавлено 22.10.2014 в 02:09 ----------

Я в плане проектирования БД newbe. :(

Вот вам отрывок кода

<article>
				<header>
					<h1>Neque porro quisquam est qui dolorem</h1><time datetime="2014-09-02T00:00:00+0000">Yesterday</time>
				</header>
				<figure>
					<img src="/image/poster.jpg" alt>
					<figcaption>Suspendisse ipsum risus, ullamcorper nec ultrices id, blandit nec lorem.</figcaption>
				</figure>
				<section id="1">
					<header>
						<h2>Nullam vel convallis leo, aliquam feugiat turpis. In varius tortor mollis faucibus vestibulum.</h2><a class="button" href="#1">Mark chapther</a>
					</header>
					<p>Nullam vel convallis leo, aliquam feugiat turpis.</p>
				</section>
			</article>

В данном случае, figure относится к section, у которого нету title, а в этом случае, section опускается в форматировании.

В БД хранится только название ресурса figure, а полный адрес задает система. В случае же хранения HTML кода, мне бы опять-таки, пришлось бы изощрятся с regex.

Если INSERT я еще могу представить с помощью транзакции, то выборку из 3 таблиц трудно. Тем-более FULL OUTER в MySQL нету. Хотя это именно то, что я хочу получать в ответ.

ortegas, понять бы еще, зачем вы хотите выделять из текста по regexp его внутреннюю структуру, зачем она вам? Хочется именно выяснить какую цель приследуете. Вы делаете свою CMS? у которой разработчиком сайта и наполнителем контента будет конечный пользователь?

iqmaker, тривиальный пример, вставить в последний абзац аннотации кнопку "Читать далее". Если структуру абзацев не выделить, надо либо regex, либо DOMDocument.

Следующий пример - заголовок секции (h2). Возле него, должна выводится кнопка "Добавить в закладки". Закладка на секции должна запоминаться на стороне сервера.

Третий пример - списки. Возле каждого li, в зависимости от раздела, а именно в разделе с кулинарными рецептами, должны присутствовать checkbox, которые запоминаются на стороне сервера, чтобы пользователь вернувшись, увидел то самое состояние списка.

В случае хранения HTML кода, мне постоянно надо выполнять массу regex. А закладки и состояния списка все-равно нужно хранить привязав к пользователю, только вместо FK, там что я укажу??? Номер секции по счету? Так при редактировании статьи, мне надо будет все закладки переписать что ли?

Ну и опять-таки, стараюсь свести все к нормальному состоянию. Я все-таки новичок и лишняя формализация = не лишняя.

ortegas, ок становится немного прозрачнее, что не совсем CMS, а некоторый сайт со своей спецификой и внутренними объектами так? Объекты страницы чем отличаются друг от друга?

---------- Добавлено 22.10.2014 в 15:21 ----------

Что-то мне подсказывает, что можно обойтись структурой которую указал в первом посте, добавив в таблицу Section поле section_type ...

---------- Добавлено 22.10.2014 в 15:23 ----------

Но в целом в вашем варианте нет ничего плохого, если выборка из 3 таблиц тремя запросами это вполне себе ок, для такого варианта сайта в котором несколько типов объектов.

---------- Добавлено 22.10.2014 в 15:25 ----------

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

iqmaker, в первую очередь, это статьи. Специфика - чисто моя инициатива. Смотрите.

Статья разделена на секции для удобства чтения. Каждую секцию можно добавить в закладки с помощью кнопочки, которая отображается справа от h2 заголовка секции. При последующем открытии статьи с помеченной секцией, пользователь будет сразу же переброшен на часть, где он завершил чтении через #section-#.

В статье могут присутствовать интерактивные списки. Хороший пример - список закупок для приготовления рецепта.

• Майонез.
• Артишоки.
Касательно фигур, тут тоже хотелось бы хранить адрес на изображение отдельно. Точнее, внутренний идентификатор изображения. Почему? - Я планирую подключения CloudFire. Соответственно, если я буду хранить фигуры в HTML коде, мне придется переписывать все адреса изображения руками с относительных внутредоменных на CDN.

---------- Добавлено 22.10.2014 в 14:30 ----------


iqmaker:
Но в целом в вашем варианте нет ничего плохого, если выборка из 3 таблиц тремя запросами это вполне себе ок, для такого варианта сайта в котором несколько типов объектов.
И еще вопрос: как в моем случае сохранять позицию объекта относительно статьи? Отдельное поле position для каждого дочериного объекта? А не плохо ли то, что эта position будет зависеть от других соседних объектов с другим типом? Например, figure.position = 1, paragraph.position = 2. Но при этом, 2 не имеет смысла без 1?

---------- Добавлено 22.10.2014 в 14:39 ----------

Добавить в закладки по h2 некоторой статьи можно чисто javascript + cookies, ( пронумеровав их при загрузке страницы тем же javascript ) или хочется на разных устройствах помнить?

В общем если правильно понял расчитываете на зарегистрированного пользователя .. ок ( если нет то тоже js мог справиться )

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

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

Обычно join показывает результат равный или худший нежели два отдельных под запроса этого join, только тест скажет как будет в конкретном случае и какие именно данные будете доставать, но чуда вероятно не случится.

Ничего плохого нет, только уверены, что не хотите использовать таблицу связей (там и указывать позицию), ведь некоторую figure и др. объекты данной статьи можно было бы использовать в другой. Почему 2 не имеет смысла без 1? чем меньше тем выше, хоть -100 -10 0 10, какое именно число на мой взгляд не важно, вам же нужно только ранжировать.

Наверное лучше использовать общую с параграфом таблицу, если только вы эти strong не начнете использовать в других статьях отдельных от первоначального параграфа.

---------- Добавлено 22.10.2014 в 16:15 ----------

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

Cookie = лишний трафик, JS - замедляет сайт на стороне клиента. У меня приоритет именно на клиента, а как там оно работает уже моя задача.

Рассчитываю прежде всего на сессии. Это единственный ключ, который записывается в Cookie сроком на 1 год. Но снова-таки, пользователь к сессии может быть определен.

Фигура в моем понимание это прежде всего figcaption. Фактически, это параграф с ресурсом. А один и тот же параграф вряд ли я буду вставлять в разные статьи.

Не хочется спорить но cookie это максимум 4кб :)), js замедлит если делать анимации и пр. лабудень, для $(el).attr( 'id', 'any' ), вы ничего не заметите, но такими мыслями серьезно себя ограничиваете в функционале.

Вы там выше написали о том, что это может быть картинка, видео, аудио, поэтому почему нет, ведь все эти объекты могут использоваться в нескольких статьях, но вам виднее как именно будет в вашем случае

Или мобильный телефон с Opera Mini...

Я же не утверждаю, я же спрашиваю. Сам ничего не решил. Наверное, лучше хранить figcaption и p в одной таблице paragraph с полем resource, который уже будет FK на таблицу resource. Поле resource NULL - оформляем, как параграф, не ноль, запрашиваем ресурс и оформляем, как figure.

Так лучше?