Несколько лет назад я попробовал сделать сайт на такой системе как MODx и он мне понравился, несмотря на мой опыт работы с другими CMS, а может и благодаря ему.
Мне понравилась логика работы с ним, принципы структуры данных и многое другое, но в первую очередь, что особенно часто нужно фрилансеру, так это простота и скорость запуска проекта с высокой гибкостью.
Но, хотя MODx мне все равно нравится, пост не совсем о нем и даже больше что-то совершенно другое .
Введение
На самом деле я просматриваю эту cms просто как пример , то, что присутствует во многих системах с открытым исходным кодом и коммерческих системах.Просто мне, как фрилансеру, до недавнего времени практически всегда приходилось работать с разработкой сайтов дешевле и быстрее — может, у других фрилансеров много «толстых» клиентов, не знаю, не знал.
Так что эта ситуация привела к хорошему опыту работы над Modax. Но открытие собственной компании и дальнейшее привлечение клиентов с индивидуальными запросами потребовало от меня вспомнить и повысить свой уровень реального программирования и построения баз данных.
И тут я почувствовал какой-то дискомфорт или как минимум смущение, вспоминая структуру как MODx, так и некоторых других открытых систем.
Далее я объясню подробнее, что именно показалось странным, но интересным.
Дело в том, что в MODx Revo основной концепцией построения структуры сайта являются ресурсы.
Правильно, не существует такого понятия, как, например, в WordPress есть отдельные страницы сайта и отдельные записи в блоге.
Все страницы и публикации и даже многое другое реализованы через модель ресурсов сайта.
На самом деле это удобно, особенно учитывая тот факт, что это cmf/cms, то есть система предназначена для разработки совершенно разных сайтов, как тематически, так и технически.
Таким образом, удобно контролировать всю структуру сайта в одной панели управления ресурсом.
В целом система ресурсов позволяет создавать и управлять следующими сущностями сайта (я хотел написать объекты, но в ООП это слово уже занято, поэтому пусть это будут «сущности»): • Обычные html-страницы; • Различные категории и разделы блога или каталога; • Товары и их категории; • XML-документы, например sitemap.xml для поисковых роботов; • Текстовые документы, например, robots.txt, следует превращать в ресурс, а не просто заполнять файлом; • Json-страницы, которые лично я использую для того же Ajax; • Создайте свой собственный формат текстового файла.
Постановка задачи
Именно такое объединение множества разных «сущностей» сайта в объекте одной модели Resources и вызвало у меня интерес.Ум философа зашевелился и стал выдвигать множество предположений и вопросов.
Во-первых, я обратил внимание на пользователей, потому что они сделаны совершенно отдельно от ресурсов.
На первый взгляд это кажется логичным, но с другой стороны, если вы затеяли такой танец с объединением кучи всего, почему бы не сделать все до конца.
Да-да, максимализм в действии.
Тем более, что сделать пользователей одним из видов ресурсов не является большой проблемой.
В случае с modx это по большей части реализовано с помощью заполнителей, позволяющих расширить количество атрибутов ресурса, и «контекстов», позволяющих выделить часть ресурсов по назначению.
Реализовать что-то подобное на фреймворке (я имею в виду PHP-фреймворки) или голой связке скриптов и реляционной базы данных совсем не сложно.
Во-вторых, шаблоны и вся система представления и настройки сайта реализованы в совершенно отдельных моделях.
Почему бы не объединить их в одну модель хотя бы чисто ради эксперимента.
Я чувствую, как в меня летят помидоры.
От частного к общему
Обобщение — это абстракция, которая позволяет представить класс отдельных объектов в общем виде как один именованный объект. Джон М.По сути, это продолжение работ натурфилософов, только перенесенное в плоскость хранения данных: «Что такое единое» и стоит ли идти на обобщение при проектировании базы данных? Под обобщением, или переходом от частного к общему, я подразумеваю именно объединение нескольких моделей на уровне проекта MVC и соответственно таблиц на уровне базы данных, что я заметил в modx. Хотя в ситуации с базой данных объединяются не таблицы, а ключевые атрибуты (так называемый первичный ключ), что приводит к объединению таблиц.Смит, Дайана К.
Смит
Но это не значит, что такую структуру невозможно привести к нормальной форме.
Давайте рассмотрим чисто гипотетический пример.
При проектировании базы данных нам необходимо было хранить и предоставлять доступ нескольким «сущностям» веб-приложения: администраторам сайта с разными ролями и правами; клиенты; страницы сайта; теги; товары; категории.
Существует несколько способов создания базы данных.
И я не говорю о нормализации базы данных, которую необходимо сделать, приводящую к третьему типу.
Я имею в виду количество или, можно сказать, разнообразие первичные ключи .
Самым естественным и распространенным решением было бы сделать все «как сказали», то есть для каждой «сущности» свой первичный ключ и набор неключевых атрибутов, которые при нормализации можно разделить на отдельные таблицы ( см.
рис.
выше).
Но такое решение вызывает ряд вопросов и проблем.
А если вопросы типа «Почему бы не объединить администраторов и клиентов в пользователей с разными уровнями доступаЭ» ты можешь просто забить.
Тогда вам придется разобраться с проблемами.
Что касается администраторов, вам необходимо решить, как определить их роли и права доступа.
Альтернатива — создать еще одну «сущность» или даже две отдельные для прав и для ролей.
Кроме того, появляется важный атрибут определения роли, который будут решать эти «сущности», либо, если они не созданы на уровне базы данных и определены на php (кто пишет сайты и приложения на другом языке, представьте себе, что я здесь упоминалось об этом, а не в php), то этот атрибут необходимо создать как отдельное поле.
Есть еще одно решение – повысить уровень генерализации базы данных.
Вы можете объединить всех пользователей в один ключевой атрибут, чтобы все администраторы и все клиенты были пользователями.
Но нам нужно как-то их различать; для этого нам придется ввести неключевой атрибут роли, который, в общем-то, у нас был в первом методе, но не применялся к клиентам.
Таким же образом мы можем объединить страницы сайта, категории, товары и теги в объект «ресурсы».
И здесь нам также понадобится дополнительный неключевой атрибут, позволяющий определить, какую «сущность» представляет тот или иной ресурс.
И опять же, все это можно вернуть в норму.
Из таких соображений возникает желание понять, насколько высоко может подняться уровень генерализации данных.
Вполне можно предположить, что пользователи — это всего лишь один тип ресурсов.
Если вспомнить опыт modx, который навел меня на такие мысли, то помимо описанных выше «сущностей» нужно добавить роли пользователей, права доступа, шаблоны и некоторые другие, так сказать, сопутствующие данные, такие как настройки системы в базу данных.
И даже их всех можно объединить в общий уровень обобщения – «предметы».
«Ресурсы» тоже прекрасно вписываются в него.
Теперь нам просто нужно, чтобы каждый элемент уровня объекта имел атрибут, определяющий, какой «сущности» он принадлежит. 
Это то, что мы можем увидеть, продвигаясь вверх по уровням обобщения.
Во-первых, для реализации необходим, как теперь выясняется, еще и ключевой атрибут, определяющий положение «сущности» на более низких уровнях, — «атрибут обобщения».
Он должен отражать ценность на самом низком уровне, каким только может быть.
Например, для одного из администраторов сайта это может иметь значение «контент-менеджер», для других — «программист» и т. д. Во-вторых, поднимаясь вверх, мы наконец приходим к выводу, что все данные в базе данных разделены на объекты и атрибуты.
По сути, объекты — это те же поля таблицы, но ключевые и отражающие значение атрибута обобщения.
В-третьих, все уровни обобщения, кроме разве что самого верхнего, позволяют привести базу к нормальному виду, хотя они могут показаться просто самым безумным решением.
Более того, они могут оказаться таковыми.
Давайте представим, что у нас есть тысяча страниц, тегов и клиентов, администраторов и настроек, всего пусть будет тысяча.
Получается, что на уровне объектов они все будут храниться в одной таблице, даже если мы сделали нормализацию и перенесли атрибуты в другие таблицы.
А что если объектов в десятки раз больше?
Минимальное обобщение
Мы решили, конечно, частично повысить уровень.И хотя в этом есть свои преимущества, такие как высокий уровень абстракции, даже заоблачный, недостатков все же больше.
На мой взгляд их слишком много, особенно если делать хайлоад. Предлагаю посмотреть, насколько низко можно понизить уровень обобщения и какие плюсы и минусы это может иметь по сравнению с «обычным» уровнем.
На самом деле определить, насколько низкий уровень обобщения возможен только при конкретной задаче и результат обязательно будет только для нее.
Давайте посмотрим, что мы можем сделать на нашем примере.
Конечно, мы не будем относить клиентов к пользователям.
Далее мы разделим администраторов на нужные нам роли, тем самым избавившись от них, и оставив в качестве атрибутов для каждого из них только права.
Думаю, это будет примерно так: контент-менеджеры, SEO-админы (скорее всего будут такие), программисты.
Также разделим ресурсы на отдельные части, тем самым избавив от необходимости указывать, какой «сущностью» является каждая из них.
Как мы видим, атрибут обобщения больше не нужен; оказывается, свою роль играют сами данные.
А это позволяет избавиться не только от атрибута, но и от таблицы, а возможно и не от одной, учитывая, что количество атрибутов для ресурсов и пользователей может быть достаточно большим.
Разбивая всё и вся на части, мы получаем большее количество таблиц.
Теперь пользователи занимают не одну таблицу, за исключением любых таблиц с дополнительными атрибутами, а в нашем примере четыре.
То же самое происходит и с ресурсами, которые представляли собой одну таблицу.
И с одной стороны, увеличивается количество таблиц, но с другой стороны, стоит отметить, что мы не учитываем, как изменится база данных после ее нормализации.
Также отметим еще два положительных эффекта, особенно приятных при разработке нагруженных приложений.
Количество строк в каждой таблице становится меньше, и здесь существует прямая зависимость между уровнем обобщения и загруженностью таблиц.
Но при нормализации такой зависимости нет; более того, может быть и наоборот. И еще один плюс, конечно, если правильно пользоваться, это конкретная цель использования каждой таблицы.
Здесь нет никакой двусмысленности, как в случае с высокими уровнями обобщения баз данных.
И хотя большее количество таблиц, на первый взгляд, усложняет проект, при правильном именовании таблиц, сопровождении моделей (если они используются) пояснениями в комментариях это может послужить большей прозрачности в работе с базой данных.
.
С другой стороны, уровень абстракции реализации базы данных падает, и это может оказать медвежью услугу.
Так, например, если появляется новый тип администратора, то на высоком уровне нам достаточно добавить к атрибуту обобщения лишь одно дополнительное значение.
Затем вы можете создать новых пользователей и назначить им это значение.
При минимальной абстракции обобщения такая красота не получится; вам придется создать новую основную таблицу для этого типа администратора, а также различные дополнительные или осуществить подключение к уже существующим.
И возникает вопрос: «А что если добавить не новый тип пользователя, а новый уровень внизЭ», например, программисты вдруг разделились на бэкенд и фронтенд.
Заключение
Здесь представлены только мои теоретические рассуждения на тему «А что, если.», практического применения почти не дано.
Лучшая и самая полезная статья, которую я нашел по этой теме, — это статья Джона и Дианы Смит «Абстракции баз данных: агрегирование и обобщение».
Они профессионально описали то, что я пытался здесь донести.
Я хочу попробовать нагрузочное тестирование на разных уровнях обобщения.
Мира и любви всем.
Теги: #реляционные базы данных #проектирование баз данных #modx Revolution #sql
-
Sony Clie Nx70V: Лопата Нашей Молодости
19 Oct, 24 -
По Поводу Блогов И Их Хранителей.
19 Oct, 24 -
Хабр Снова В Опасности!
19 Oct, 24 -
Таблица Дроидов. Выпуск 20
19 Oct, 24 -
Qr-Статья 2: «Структура Qr-Символа»
19 Oct, 24
