Чуть больше чем просто блог :)

BeeCMS::Структура и проектирование базы данных MySQL Избранное

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


Перед тем как читать данную статью советую сперва ознакомится с предыдущей публикацией «BeeCMS::Файловая структура проекта» чтобы иметь более глубокое представление структуры и глубже понять причину создания именно такой структуры базы данных.

В помощь вам также следующие статьи, которые помогут раскрыть глубже тему и приведут к оптимальному решению при построении архитектуры:

Начальная архитектура должна соответствовать правилам, описанным в приведенных статьях выше. Развивая проект в дальнейшем мы так-же обязаны будем им следовать для целостности всего проекта и пониманию как нами, так и другими разработчиками. Данные правила мы потом поместим в мануал для разработчиков нашей системы управления.

Общие правила:

  • Архитектура БД не должна нарушать целосность базы
  • Не смешивать данные и метаданные. Данные- эта хранимая информация, они должны хранится в виде строк. Метаданные - это структура таблиц и содержатся в столбцах таблицы.
  • Приставка «pre_» в текущей вариации означает приставку, которую мы будем в дальнейшем настраивать в проекте и генерировать автоматически при установке. Это даст небольшую дополнительную защиту нашей БД от взлома.
  • Первый столбец всегда будет автоинкрементным IDшником и первичным ключом для конкретной таблицы;
  • Первый столбец всегда будет включать название таблицы, а затем приставку _id. Например, category_id – означает, что таблица называется category;
  • Все целочисленные столбцы, не имеющие отрицательных значений, указываем как «Беззнаковый»;
  • Все числовые и текстовые типы, имеющие возможность указывать максимальную длинну значения – должны быть указанны и содержать только достаточное количество значений. Не больше и не меньше. Например, в таблице меню столбец «menu_id» будет иметь тип smallint(4), содержащий максимум 9999 строк, потому как сложно представить себе сайт содержащий пунктов меню более этого значения. А уже подстраниц может быть бесконечно много. Или другой пример: Длинное название в Title плохо сказывается на продвижении. Хорошим тоном считается заголовок в 50 – 80 символов. Добавим немного запаса и получим 100 символов. Больше пространства давать пользователю вредно.
  • Логические значения, такие как (Опубликован/Не опубликован); (По умолчанию/Не основной); (Выделенный/Обычный)... всегда будут начинаться с приставки «is_»;
  • Все логические значения и списки выборки будут назначаться типом «tinyint» с добавлением констант с расширенным названием в моделях. При этом tinyint(1) – обязательно указывается для логических значений и списков меньше 10. Для больших списков ставим (2) если нужно использовать до 99 вариантов, либо (3) для очень больших выпадающих списков. Важно чтобы этот тип был беззнаковым. Максимальное значение типа tinyint = 255.
  • Дата всегда будет начинаться с приставки «data_» а затем ее назначение;
  • Столбцы содержащие дату обновления для отслеживания актуальности кэша обязательно должны быть приведены к типу «DATETIME»;
  • Языковые таблицы содержат только данные с переводом и являются дополнительными к основным таблицам;
  • Вложенные множества строк будем создавать с помощью модели «Nested Sets» для формирования деревьев и управления ими. Об этом методе очень хорошо написано в этой статье: http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql;
  • Все таблицы и столбцы должны иметь комментарии.

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

Первоначальная архитектура

На текущий момент важно создать общую концепцию архитектуры, содержащий только самый основной функционал, необходимый для управления страницами сайта. В него будет входить такие базовые функции CMS:

  • Хранение и управление языковыми версиями;
  • Расширения и управления ими. (Бывшие «Модули». Смотри пункт Терминология в статье «BeeCMS::Файловая структура проекта»);
  • Пользователи – пока рассмотрим стандартный функционал от Yii2;
  • Миграции – пока тоже стандартные, потом расширим этот функционал;
  • И предустановленные базовые расширения:
    • Меню;
    • Категории;
    • Статические страницы;
    • Блог.

Таблица языков приложения:

Данная таблица будет только содержать языковые версии приложений без каких либо связей с другими таблицами. Добавлять/Изменять их сможет только разработчик, а администратор сможет включать/выключать их, выводить виджет переключения языков и устанавливать один из них языком по умолчанию для всех приложений.

Описание столбцов:

language_id - ID языка. Беззнаковый, поскольку никогда не будет меньше нуля. Автоинкрементный,
is_published - Публикация,
ordering - Порядок вывода языков,
is_default - Основной язык по умолчанию,
language_code - URL ссылка выбранного языка,
language_local - Код языка,
name - Название языка,
title - Вывод названия языка,
flag - Изображение флага,
date_create - Дата установки языкового пакета,
date_update - Дата редактирования языкового пакета.

Таблица Расширений и дополнительные к ней:

Таблица «pre_extension_zone» будет содержать зоны приложений, такие как: developer, administrator, frontend и возможно другие, если захотим расширить в дальнейшем. Для первичного ключа указан тип tinyint со значением (1). Этого нам будет достаточно, поскольку врядли их будет больше 9. Даже если добавим в дальнейшем еще «Console» и «Tests», то в сумме мы получим 5 строк, что гораздо меньше 9.

Таблица «pre_extension_module» будет содержать в себе данные о расширениях. А именно его ID, название на транслите, код названия для мультиязычности, статус публикации и основные параметры для всего расширения. Название может быть например уже заезженый нами «Blog» или «Интернет-магазин»...

«pre_extension_controller» содержит перечень различных наименований контроллеров, которые могут быть в любом из расширений. Название контроллеров должно быть уникальным. Это не значит, что нам постоянно нужно выдумывать новые названия. В дальнейшем, одни из них мы будем их назначать для некоторых расширений, а другие – для других. При этом иногда у нас названия могут повторятся, и мы без проблем сможем их использовать и для других расширений. Если запутались – продолжайте читать, дальше станет понятно. Названия контроллеров могут быть к примеру: «Defoult», «Posts», «Cart»...

«pre_extension_action» также, как и контроллеры будем назначать их отдельно в основной таблице. Примеры названия действий: «index», «mail», «error»...
И наконец «pre_extension». В этой таблице мы будем собирать все 4 вышеописанные таблицы в одну. Формируя таким образом все действия для каждого контроллера всего модуля. То есть в этой таблице мы сможем собирать любые вариации 4х таблиц без дублей строк. И дополнительно сможем применять статус к каждому действия и хранить дополнительные настройки. А связи ключей будут блюсти целостность базы.

Пример 1: у нас есть расширение «Блог» который будет выполнять все те же действия стандартного контроллера, но для разных приложений. Для этого нам нужно создать 2 записи:

Зона Расширние Контроллер Действие
administrator Blog Dafoult index
frontend Blog Dafoult index

И таким образом получим одинаковые названия, но разное отображение информации. Оптимизированное специально либо для администратора, либо для пользователя сайта.

Пример 2: У нас есть каталог товаров и мы хотим сделать переключение вывода товаров с списка на вывод товаров в виде сетки. Для этого нам потребуются 2 действия «list» и «grid» с контроллера «Catalog», а все остальное будет без изменений:

Зона Расширние Контроллер Действие
frontend Shop Catalog list
frontend Shop Catalog grid

Таблица пользователей:

Данная таблица устанавливается при установке Yii2 фреймворка. Она пока останется без изменений.

Таблица Миграций:

Данная таблица устанавливается при установке Yii2 фреймворка. Она тоже пока останется без изменений. В дальнейшем ей будет удобно применять демо данные для новых сайтов и вносить данные для тестирования при разработке.

Таблицы Меню:

Для меню будет создана дополнительная таблица «pre_menu_type», хранящая в себе типы меню например: «Главное меню», «Меню пользователя» и т.д.

В основной таблице «pre_menu» будем хранить следующие данные:

menu_id - ID пункта меню,
parent_id - Родительский пункт меню,
is_published – Опубликованно/Не опубликованно,
is_menu_displayed - Отображать в меню или скрыть. При этом ссылка рабочая,
menutype_id - ID блока меню,
extension_id - ID приложения,
alias - Адрес ссылки,
image - Изображение ссылки меню,
is_home - Назначить главной страницей,
params - Параметры,
date_update - Дата редактирования,
level - Уровень вложенности меню,
lft - Вложенный набор lft.,
rgt - Вложенный набор rgt.

Таблицы с приставками «_ru», «_en» и «_ua» содержат в себе только данные перевода заголовка ссылки и возможного подзаголовка.

Стоит отдельно отметить столбцы «alias» и «image». Пока добавил их в основную таблицу, поскольку ссылки зачастую пользователи не вводят, и мы будем их генерировать автоматически. Таким образом ссылки страницы для языковых версий будут одинаковыми. Будет меняться только языковая приставка. Это хорошо как для СЕО, так и для уменьшения количества дополнительных проверок и запросов к БД.

Что касается изображений, то может понадобится изменить изображение в зависимости от языка. Но пока мне кажется это мало вероятным.

Интересно будет послушать ваши мысли по этому поводу. Оставляйте в коментах.

Таблицы Категорий:

Основная таблица категорий «pre_category» будет содержать следующие данные:

category_id - ID категории контента,
parent_id - Родительская категория,
extension_id - ID приложения,
is_published - Публикация,
alias - Ссылка на категорию,
image - Изображение,
user_id_create - Автор создания категории,
data_create - Дата создания категории,
user_id_update - Автор редактирования категории,
data_update - Дата редактирования категории,
hits - Количество просмотров,
params - Параметры,
level - Уровень вложенности категории,
lft - Вложенный набор lft.,
rgt - Вложенный набор rgt.

А второстепенные таблицы с приставками языков будут хранить только информацию о переводах каждой категории, которые будут объединятся при определенном запросе с приставкой языка.

Таблицы Статических страниц:

Для статических страниц создана дополнительная таблица «pre_category_content_page», которая связана с основной таблицей категорий. На этой картинке ее не видно. Покажу все дополнительные связи в конце этой статьи после того, как рассмотрим частные случаи. Так будет легче понять всю картину.

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

Основная таблица «pre_ page» содержит следующую информацию:

page_id - ID статической страницы,
extension_id - ID приложения,
is_published - Публикация,
data_publish_up - Дата начала публикации,
data_publish_down - Дата окончания публикации,
alias - Ссылка на страницу,
image - Главное изображение,
is_featured - Выделить страницу,
user_id_create - Автор создания страницы,
data_create - Дата создания,
user_id_update - Автор редактирования страницы,
data_update - Дата редактирования,
hits - Количество просмотров страницы,
params - Дополнительные параметры выводом страницы

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

Таблицы Блога:

Если присмотреться, то можно увидеть значительное сходство с таблицами для статических страниц. И это так и есть. Добавил только столбцы для вывода в специальном месте видео, галереи и возможностью голосования пользователей.

Кстати столбец «Vote», предназначенный для голосования может принимать как положительные, так и отрицательные числа, поскольку мы ж можем и засрать пост если не нравится . Ну это стоит сделать как дополнительную опцию.

В итоге архитектура всего проекта со связями будет выглядеть так:

MySQL-structura-m

SQL запросы для создания этих таблиц со связями можно скачать по ссылке
Предварительно создайте БД с названием «bee_cms», ну либо переименуйте на вашу в скачанном файле.
Попробуйте еще скачать диаграмму расположения таблиц со связями. Запускайте ее после того как выполнятся все запросы создания таблиц и связей. Но мне кажется что он не подтянется. Если таки не подтянется, то в программе «dbForgeForMySQL» создайте новую диаграмму и просто перетащите на нее все таблицы. Расположение конечно будет другим, но можно вручную выстроить как нравится :)


На сегодня это все!
В следующий раз перейдем уже к непосредственной установке и первоначальной настройке проекта.

Буду благодарен за комментарии, а особенно благодарен если поделитесь в соц-сети со своими друзьями нажав на кнопки ниже!

Другие материалы в этой категории: « BeeCMS::Файловая структура проекта

Оставить комментарий

Убедитесь, что вы вводите (*) необходимую информацию, где нужно
HTML-коды запрещены

Авторизация