Здравствуйте!

Задача такая:

Есть некий CMS для хранения текста, картинок, таблиц, файлов, видео и аудио. CMS предназначена не для HTML. Контент выдергивается некими плеерами (desktop, mobile) и интерпретируется в виде статей.

Сущность "статья" имеет следующую структуру:

Заголовок

Подзаголовок

Нумерованный список элементов контента (content_element: id, type, title, subtitle, text, url, pos, created_at, updated_at). Это может быть текст, ссылка на картинку, ссылка на видео и т.п

Нумерованный список атрибутов контента (content_attribute: id, key, value, pos, created_at, updated_at). Key->value значения, которые описывают статью или используются для отображения двух колоночной таблицы характеристик в статье.

Позиция статьи в списке статей

Дата создания

Дата обновления

Кроме текста, нужно хранить в элементах статьи еще и таблицы.

Как (какие сделать поля или использовать разметку типа textile что не желательно) можно сделать таблицу,
чтобы можно было любые 2-мерные сущности (таблицы в контенте) разбивать и складывать в эту таблицу и соответственно выдергивать по указанным значениям полей. У любой статьи есть идентификатор базы и идентификатор пользователя.

Спасибо!

Да, я примерно представляю как это работает.


Сущность = { ContentId, AttributeId, AttributeValue }
Для таблицы где, есть набор из двух полей, укладывается легко.
Например:

Танк Т-34

Длина корпуса, мм: 5920
Длина с пушкой вперёд, мм: 5964
Ширина корпуса, мм: 3000
Высота, мм: 2405
Клиренс, мм: 400

А если так?

Таблица расходов топлива танка Т-34

Топливо / летом / зимой /
Д.Т. 95 / 100 км - 50л / 100 км - 60л /
Д.Т. 85 / 100 км - 60л / 100 км - 65л /

Кот Матроскин,

А contentId куда?

Dimitry SibiryakovА лучше не маяться и хранить контент в BLOB сразу в языке разметки - HTML, Tex и т.п.
Нужные для поиска параметры - вытащить отдельно.


Господа, сразу говорю, контент не для сайта.
А для нативных приложений под ios, android, wp.

Браузера в этой цепочке нет.

Кот МатроскинДля хранения разных таблиц можно добавить поле Table, в которое писать для Вашего примера "Таблица расходов топлива танка Т-34"

Ну вот в классический EAV не влезает, нужно еще одно поле, а потом еще, еще...

Dimitry Sibiryakovnodir_azamГоспода, сразу говорю, контент не для сайта.
А для нативных приложений под ios, android, wp.
Пофиг. В любом случае существует некоторый "готовый" формат содержимого для отображения.


Нету.
Там только есть типы контента. Нет форматирования никакого, ответственно заявляю.

Кот МатроскинDimitry Sibiryakovпропущено...

Не придётся. CSS изобрели не сегодня. И даже не вчера.

При чем тут CSS? Вы CSS-ом будете, например, таблицу транспонировать (уж не говорю фильтровать-расширять)?

nodir_azam Ну вот в классический EAV не влезает, нужно еще одно поле, а потом еще, еще...

Классический EAV строится не из одной таблицы, как в Вашем исходном письме и моем примере, а из четырех
Ваш расход топлива можно впихнуть и в классический EAV с главной таблицей из трех полей, просто это расписывать долго и лениво.
Вкратце - Таблица "расход топлива" будет у Вас типом сущности, каждая строка таблицы - экземпляром этой сущности,
"летом","зимой" - атрибутами сущности, "Д.Т. 95 " - значением специального дополнительного атрибута сущности RowName


В том то и дело, что гибкость и универсальность страдает.
У меня потом будут типы spatial, int, float и по этим полям надо будет искать.
В вашем примере, это всегда +1 поле, которое описывает, например, тип атрибута.
Другое решение я не нашел и решил написать сюда.

Кот Матроскин
Расширения EAV для полей разных типов - тоже не big deal и описаны много где (вкратце - это либо добавление в основную таблицу полей IntValue, DateValue и т.п., либо разбиение этой основной таблицы на несколько с полями соответствующих типов).
Я бы на Вашем месте все же не изобретал велосипед.

Согласен. Я принципе так и сделал.
Получается так:

key valueД.Т. 95. Летом 50 лД.Т. 95. Зимой 60 лД.Т. 85. Летом 60 лД.Т. 85. Летом 65 л

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


Приложения разные. Система одна.
Одно приложение, к примеру хранит рецепты. Другое - описание моделей авто.
Третье - картинки и описание танков.

Вроде бы все хранят текст и картинки, но нет. Есть еще характеристики, в них вся разница.
Хранить в блобе с разметкой - та еще задача. На клиенте надо эту разметку распознать
и интерпретировать. Клиент не браузер, еще раз повторюсь.

SERG1257И вы хотите сделать одну базу подходящую всем, запрячь так сказать в одну телегу коня и трепетную лань. Не боитесь что получившееся универсальное решение будет универсально плохо работать со всеми приложениями? Не проще ли будет сделать несколько похожих, но заточенных решений?


Нет, не боюсь. В том-то и фишка. Одно серверное решение (CMS) позволяет сократить издержки и время публикации контентных приложений в разы, а может и на порядок. Даже можно было бы наверно использовать готовый, если бы клиент был на браузере. В нашей системе важен контент, а способ его отображения. Универсальность имеет большой смысл.
Уж клиент данные в формате JSON обыграет, и качественно, в этом сомнений нет.

nodir_azamВ нашей системе важен контент, а способ его отображения.
В нашей системе важен контент, а не способ его отображения.

SERG1257Ну меня не надо за советскую власть агитировать.
Еще раз в вашем предложении меня интересуют глаголы:
то бишь как клиент наполняет контент,
как ее ищет,
в каком формате получает найденое.

Если все ваши приложения делают это одинаково - поиск по ключевым словам, датам, автору, маске в заголовке и т.п. то для базы они все одинаковые.

Клиент получает списки, получает по каждому списку набор текстов, ссылки к картинкам. Поиск делает в своем локальной (sqlite) базе. То, что меняется часто, обновляет через API. В прочем локальную базу тоже, время от времени наполняет через API. CMS нужен для сбора, организации структуры каталогов и создания статей. Клиент берез слепок, все манипуляции с данными делает уже сам. Мне нужно сделать инструмент, который собирает, структурирует и частями отдает клиенту. Поиск - проблема клиента.

На стороне CMS поиск нужен, возможно для только отчетов и статистики.
Но это уже не такая большая проблема. Я могу роботом собирать данные и писать куда-нибудь в Redis например.
Чтобы отображалось быстро.

SERG1257То бишь зашел клиент и получил сразу копию всего сайта.

Ну в общем да.
Ну во первых это не сайт, а приложение из максимум 20-ти статей, со своей структурой, то есть, категориями, разделами.
Да и брать он будет по мере надобности, а списки брать сразу. Списки - это только заголовки, ну возможно еще небольшие превью картинок. Будет брать и сразу кешировать в локальную БД.

Для меня главная задача сейчас, сделать редактор, позволяющий хранить картинки (URL, сами картинки в облаке), текст и характеристики статьи. Характеристики - это таблица. Она не всегда одинаковой структуры.

Есть два варианта:
1. Язык разметки, например textile или как на этом сайте <csv> данные в формате csv</csv>
2. EAV - универсальная таблица, для хранения любых структур

Вопросы:
1. Какой вариант лучше?
2. Как таблицы (название полей, значения) хранить в другой таблице?

SERG1257,

Да, ваше решение пожалуй приемлемое.
С одним но, значения могут быть еще и разных типов.
Например spatial.

Хотя с другой стороны, пусть клиент при записи в свой БД конвертит их со строки в spatial, передавать буду например, в wkt.

debloggerТанки и на бензине ходят?


Эти на диз. топливе. :) Для примера указано.

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