Слишком эгоцентрично прозвучало. Факты?
Я рекомендую WordPress. У них есть приложения для iOS. :p
iqmaker, у вас на Android Opera Turbo прокси, наверное. Попробуйте в настройках изменить на Mini. ;)
Да и не о том спор. Зачем отсылать 4 КБ, если можно не отсылать? Зачем раскрывать внутренние алгоритмы, если можно работать по токену?
Какие проблемы position я вижу. - При перемещении абзаца вверх, нужно менять позицию и для всех следующих абзацев. Может у кого-то есть мысли по этому поводу? Какие минусы позиции в FLOAT?
Или мобильный телефон с Opera Mini...
Я же не утверждаю, я же спрашиваю. Сам ничего не решил. Наверное, лучше хранить figcaption и p в одной таблице paragraph с полем resource, который уже будет FK на таблицу resource. Поле resource NULL - оформляем, как параграф, не ноль, запрашиваем ресурс и оформляем, как figure.
Так лучше?
Cookie = лишний трафик, JS - замедляет сайт на стороне клиента. У меня приоритет именно на клиента, а как там оно работает уже моя задача.
Рассчитываю прежде всего на сессии. Это единственный ключ, который записывается в Cookie сроком на 1 год. Но снова-таки, пользователь к сессии может быть определен.
Фигура в моем понимание это прежде всего figcaption. Фактически, это параграф с ресурсом. А один и тот же параграф вряд ли я буду вставлять в разные статьи.
edogs, большое вам спасибо за советы. Посмотрите, пожалуйста, мою параллельную тему Секционное хранение статьи в базе данных. Данный запрос, точнее часть запроса, пишется конкретно для реализации описанного в этой теме.
iqmaker, в первую очередь, это статьи. Специфика - чисто моя инициатива. Смотрите.
Статья разделена на секции для удобства чтения. Каждую секцию можно добавить в закладки с помощью кнопочки, которая отображается справа от h2 заголовка секции. При последующем открытии статьи с помеченной секцией, пользователь будет сразу же переброшен на часть, где он завершил чтении через #section-#.
В статье могут присутствовать интерактивные списки. Хороший пример - список закупок для приготовления рецепта.
iqmaker, тривиальный пример, вставить в последний абзац аннотации кнопку "Читать далее". Если структуру абзацев не выделить, надо либо regex, либо DOMDocument.
Следующий пример - заголовок секции (h2). Возле него, должна выводится кнопка "Добавить в закладки". Закладка на секции должна запоминаться на стороне сервера.
Третий пример - списки. Возле каждого li, в зависимости от раздела, а именно в разделе с кулинарными рецептами, должны присутствовать checkbox, которые запоминаются на стороне сервера, чтобы пользователь вернувшись, увидел то самое состояние списка.
В случае хранения HTML кода, мне постоянно надо выполнять массу regex. А закладки и состояния списка все-равно нужно хранить привязав к пользователю, только вместо FK, там что я укажу??? Номер секции по счету? Так при редактировании статьи, мне надо будет все закладки переписать что ли?
Ну и опять-таки, стараюсь свести все к нормальному состоянию. Я все-таки новичок и лишняя формализация = не лишняя.
Решение
SELECT * FROM (SELECT DISTINCT position FROM paragraph UNION SELECT DISTINCT position FROM figure ) t1 LEFT JOIN paragraph USING (position) LEFT JOIN figure USING (position);
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 нету. Хотя это именно то, что я хочу получать в ответ.
