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

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

Есть некий 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 обыграет, и качественно, в этом сомнений нет.