iqmaker, у вас на Android Opera Turbo прокси, наверное. Попробуйте в настройках изменить на Mini. ;)
Да и не о том спор. Зачем отсылать 4 КБ, если можно не отсылать? Зачем раскрывать внутренние алгоритмы, если можно работать по токену?
Какие проблемы position я вижу. - При перемещении абзаца вверх, нужно менять позицию и для всех следующих абзацев. Может у кого-то есть мысли по этому поводу? Какие минусы позиции в FLOAT?
iqmaker: js замедлит если делать анимации и пр. лабудень, для $(el).attr( 'id', 'any' )
Или мобильный телефон с Opera Mini...
iqmaker: Вы там выше написали о том, что это может быть картинка, видео, аудио, поэтому почему нет, ведь все эти объекты могут использоваться в нескольких статьях, но вам виднее как именно будет в вашем случае
Я же не утверждаю, я же спрашиваю. Сам ничего не решил. Наверное, лучше хранить figcaption и p в одной таблице paragraph с полем resource, который уже будет FK на таблицу resource. Поле resource NULL - оформляем, как параграф, не ноль, запрашиваем ресурс и оформляем, как figure.
iqmaker: Добавить в закладки по h2 некоторой статьи можно чисто javascript + cookies, ( пронумеровав их при загрузке страницы тем же javascript ) или хочется на разных устройствах помнить?
Cookie = лишний трафик, JS - замедляет сайт на стороне клиента. У меня приоритет именно на клиента, а как там оно работает уже моя задача.
iqmaker: В общем если правильно понял расчитываете на зарегистрированного пользователя .. ок ( если нет то тоже js мог справиться )
Рассчитываю прежде всего на сессии. Это единственный ключ, который записывается в Cookie сроком на 1 год. Но снова-таки, пользователь к сессии может быть определен.
iqmaker: ведь некоторую figure и др. объекты данной статьи можно было бы использовать в другой
Фигура в моем понимание это прежде всего figcaption. Фактически, это параграф с ресурсом. А один и тот же параграф вряд ли я буду вставлять в разные статьи.
edogs, большое вам спасибо за советы. Посмотрите, пожалуйста, мою параллельную тему Секционное хранение статьи в базе данных. Данный запрос, точнее часть запроса, пишется конкретно для реализации описанного в этой теме.
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 ----------
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);
Таблица 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 ----------
ortegas: Вы уверены, что секции надо делить на три разные таблицы? Вероятно там сильно много общего наверняка можно обойтись одной. Тогда и проблем с выборкой из трех таблиц не будет, а архитектура предполагающая FULL OUTER JOIN имхо заслуживает того, чтобы ее пересмотрели.
Я в плане проектирования БД 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 нету. Хотя это именно то, что я хочу получать в ответ.
Зря ты сделал выбор на ВП. Drupal, Bitrix вот что нужно учить
Слишком эгоцентрично прозвучало. Факты?
Я рекомендую WordPress. У них есть приложения для iOS. :p
iqmaker, у вас на Android Opera Turbo прокси, наверное. Попробуйте в настройках изменить на Mini. ;)
Да и не о том спор. Зачем отсылать 4 КБ, если можно не отсылать? Зачем раскрывать внутренние алгоритмы, если можно работать по токену?
Какие проблемы position я вижу. - При перемещении абзаца вверх, нужно менять позицию и для всех следующих абзацев. Может у кого-то есть мысли по этому поводу? Какие минусы позиции в FLOAT?
js замедлит если делать анимации и пр. лабудень, для $(el).attr( 'id', 'any' )
Или мобильный телефон с Opera Mini...
Вы там выше написали о том, что это может быть картинка, видео, аудио, поэтому почему нет, ведь все эти объекты могут использоваться в нескольких статьях, но вам виднее как именно будет в вашем случае
Я же не утверждаю, я же спрашиваю. Сам ничего не решил. Наверное, лучше хранить figcaption и p в одной таблице paragraph с полем resource, который уже будет FK на таблицу resource. Поле resource NULL - оформляем, как параграф, не ноль, запрашиваем ресурс и оформляем, как figure.
Так лучше?
Добавить в закладки по h2 некоторой статьи можно чисто javascript + cookies, ( пронумеровав их при загрузке страницы тем же javascript ) или хочется на разных устройствах помнить?
Cookie = лишний трафик, JS - замедляет сайт на стороне клиента. У меня приоритет именно на клиента, а как там оно работает уже моя задача.
В общем если правильно понял расчитываете на зарегистрированного пользователя .. ок ( если нет то тоже js мог справиться )
Рассчитываю прежде всего на сессии. Это единственный ключ, который записывается в Cookie сроком на 1 год. Но снова-таки, пользователь к сессии может быть определен.
ведь некоторую figure и др. объекты данной статьи можно было бы использовать в другой
Фигура в моем понимание это прежде всего figcaption. Фактически, это параграф с ресурсом. А один и тот же параграф вряд ли я буду вставлять в разные статьи.
edogs, большое вам спасибо за советы. Посмотрите, пожалуйста, мою параллельную тему Секционное хранение статьи в базе данных. Данный запрос, точнее часть запроса, пишется конкретно для реализации описанного в этой теме.
iqmaker, в первую очередь, это статьи. Специфика - чисто моя инициатива. Смотрите.
Статья разделена на секции для удобства чтения. Каждую секцию можно добавить в закладки с помощью кнопочки, которая отображается справа от h2 заголовка секции. При последующем открытии статьи с помеченной секцией, пользователь будет сразу же переброшен на часть, где он завершил чтении через #section-#.
В статье могут присутствовать интерактивные списки. Хороший пример - список закупок для приготовления рецепта.
Касательно фигур, тут тоже хотелось бы хранить адрес на изображение отдельно. Точнее, внутренний идентификатор изображения. Почему? - Я планирую подключения CloudFire. Соответственно, если я буду хранить фигуры в HTML коде, мне придется переписывать все адреса изображения руками с относительных внутредоменных на CDN.
iqmaker: И еще вопрос: как в моем случае сохранять позицию объекта относительно статьи? Отдельное поле position для каждого дочериного объекта? А не плохо ли то, что эта position будет зависеть от других соседних объектов с другим типом? Например, figure.position = 1, paragraph.position = 2. Но при этом, 2 не имеет смысла без 1?
---------- Добавлено 22.10.2014 в 14:30 ----------
Но в целом в вашем варианте нет ничего плохого, если выборка из 3 таблиц тремя запросами это вполне себе ок, для такого варианта сайта в котором несколько типов объектов.
---------- Добавлено 22.10.2014 в 14:39 ----------
iqmaker, тривиальный пример, вставить в последний абзац аннотации кнопку "Читать далее". Если структуру абзацев не выделить, надо либо regex, либо DOMDocument.
Следующий пример - заголовок секции (h2). Возле него, должна выводится кнопка "Добавить в закладки". Закладка на секции должна запоминаться на стороне сервера.
Третий пример - списки. Возле каждого li, в зависимости от раздела, а именно в разделе с кулинарными рецептами, должны присутствовать checkbox, которые запоминаются на стороне сервера, чтобы пользователь вернувшись, увидел то самое состояние списка.
В случае хранения HTML кода, мне постоянно надо выполнять массу regex. А закладки и состояния списка все-равно нужно хранить привязав к пользователю, только вместо FK, там что я укажу??? Номер секции по счету? Так при редактировании статьи, мне надо будет все закладки переписать что ли?
Ну и опять-таки, стараюсь свести все к нормальному состоянию. Я все-таки новичок и лишняя формализация = не лишняя.
Решение
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 ----------
Вы уверены, что секции надо делить на три разные таблицы? Вероятно там сильно много общего наверняка можно обойтись одной. Тогда и проблем с выборкой из трех таблиц не будет, а архитектура предполагающая FULL OUTER JOIN имхо заслуживает того, чтобы ее пересмотрели.
Я в плане проектирования БД newbe. :(
Вот вам отрывок кода
В данном случае, figure относится к section, у которого нету title, а в этом случае, section опускается в форматировании.
В БД хранится только название ресурса figure, а полный адрес задает система. В случае же хранения HTML кода, мне бы опять-таки, пришлось бы изощрятся с regex.
Если INSERT я еще могу представить с помощью транзакции, то выборку из 3 таблиц трудно. Тем-более FULL OUTER в MySQL нету. Хотя это именно то, что я хочу получать в ответ.