Структура контента для CMS

Question

Я работаю над модульной CMS и много думал об архитектуре контента.Мне нужна гибкая система, которая позволит легко создавать различные типы контента.У каждого типа контента есть модуль (или метод в каком-то другом модуле), который его обрабатывает.Этот модуль обрабатывает создание, манипулирование и помогает в отображении контента (представления отвечают за просмотр контента, а модули предоставляют ему информацию).

Каждый тип контента имеет свою собственную таблицу и не знает других типов контента.

Contents и Content_types - это таблицы, которые отвечают за хранение информации о контенте.

Contents
---------------------------------------------------------------------------------------
id    slug            content_type_id   in_table_id   language_id  uid       parent_id
1     about-us        1                 1             1            83j8je29  0
2     o-nama          1                 2             2            83j8je29  0
3     first-page      1                 3             1            12j83j28  0
4     prva-strana     1                 4             2            12j83j28  0
5     news            2                 1             1            mSk2919k  0
6     vijesti         2                 2             2            mSk2919k  0
7     breaking-title  3                 1             1            B8392mkA  5
8     vazna-vijest    3                 2             2            B8392mkA  6

Content_types
------------------
id   content_type 
1    page    
2    category   
3    article 

Таблица Contents содержит порцию для контента, тип контента, идентификатор контента втаблица контента такого типа, идентификатор языка, uid - который уникален для контента, поэтому мы можем легко связать многоязычный контент и идентификатор родителя.

Это таблица языков ...

Languages
---------------------------
id   friendly_name    sid
1    english          eng
2    hrvatski         cro

И это пример таблицы типов контента.

Pages
---------------------------------------------------------------
id  title       content                             author_id
1   About Us    This is a page about us blah blah   5
2   O nama      Ovo je stranica o nama              5
3   First Page  Content                             2
4   Prva strana Sadržaj                             3

Итак, как все это функционирует?

Допустим, мы переходим к: http://www.website.org/en/about-us

1. Определите язык (en) и выясните его идентификатор (который равен 1)
2. Определите слаг (about-us)
3. Выберите контент с идентификатором языка из1 и слаг «about-us»
4. Определите тип контента и in_table_id
5. Вызовите модуль, ответственный за открытие (обработку) этого типа контента
6. Модуль теперь загружен,Теперь он находит страницу с идентификатором 1 и отображает ее.

Другой пример: http://www.website.org/en/news/breaking-title

1. Определите язык (en) и выясните его идентификатор (который равен 1)
2. Определить слаг (новости)
3. У нас есть два слага (break-title)
4. Теперь мы находим контент с слагом «break-title », родитель которогоis "news"
5. Вызовите модуль, ответственный за открытие (обработку) этого типа контента
6. Модуль теперь загружен.Теперь он находит статью с идентификатором 1 и отображает ее.

Если мы перейдем к http://www.website.org/en/news/, он определит, что это категория, и вызовет модуль, отвечающий за обработку категорий, иделать то, что нам нужно (что в данном случае отображает весь дочерний контент)

Я думаю, что я придумал действительно гибкую систему, но я не очень опытный программист (мне 17 лет)Я не совсем уверен в этом, поэтому я спрашиваю вас, что вы думаете об этой концепции?

Answer 1

Я недавно стал фанатом хранения данных такого типа как метаданные .Очевидным преимуществом является то, что вы можете иметь одну таблицу для всех типов вашего контента и (имея нормированную структуру 5 дБ) максимум две дополнительные таблицы для хранения ссылок на метаданные и фактических значений метаданных.Это обеспечивает высокий уровень абстракции данных и общую модель для обеспечения устойчивости.И все эти обманчивые слова приводят к ускорению разработки.

В качестве примера: Elgg , популярная основанная на php фреймворк для социальных сетей, хорошо справляется с этим типом хранилища. Flow3 , концептуальная, но очень аккуратная, универсальная среда разработки php, также использует метаданные для устойчивости.

Самое большое преимущество подхода метаданных состоит в том, что вы можете забыть об операторах SQL в своем коде, раз и навсегда.Если у вас есть правильная абстракция постоянства, вы можете создавать постоянные объекты, такие как:

$car = new StdClass();
$car->type = 'car';
$car->fuel_required = 'petrol';
$car->engine_cc = 2400;
$car->max_passengers = 5;
$car-save();

И ваша структура постоянства позаботится о самой функции save (), перебирая свойства объекта и сохраняя их втаблицы метаданных.Если вам нужен рабочий пример всего этого, я бы снова предложил установить и попробовать Elgg.Вы увидите, что практически любой вид нового контента будет вставлен в те же 3-4 таблицы.

Существуют некоторые разногласия по поводу использования подхода метаданных, в основном на основе производительности.Несомненно, что при таком подходе ваши мета-таблицы будут заполняться очень быстро.Однако при условии, что ваши индексы на месте, ваши запросы дадут вам разумное время ответа, даже если в мета-таблицах есть десятки миллионов записей.И, что лучше всего, если вы не хотите масштабировать свою инфраструктуру по мере роста вашего бизнеса, вы можете обратиться к Amazon s3 или другому распределенному решению для хранения данных, чтобы удовлетворить ваши потребности в масштабируемости.