Архитектура CMS. Модель данных. Часть 2

    Продолжаем тему объектной модели данных. В этой части речь пойдет о модуле Data, являющимся, по сути, ORM системой. Для наглядности работы модуля Data c его помощью будет создано содержимое простого сайта. Предыдущая статья: Архитектура CMS. Модель данных. Часть 1.

    Модуль Data состоит из классов Data, Object, Multy, Query и набора классов Cond*. Сам модуль – это статический класс Data, остальные классы используются для представления структур данных, с которыми он работает. Для представления сущностей в программном коде используется класс Object. Не важно, какого типа сущность – класс данных, объект данных или связь между ними – для всех Object. Класс Multy используется для ассоциации с набором сущностей, в частности, для представления множественных свойств. Классы Query и Cond* необходимы для осуществления поиска по объектной модели (в базе данных) с учетом гибких условий.

    Чтение сущности


    Получить сущность из базы данных можно по её идентификатору следующим способом:

    $obj = Object::Create(1); // сущность с идентификатором 1

    Вместо оператора new применяется статический метод Create(). В нём проверяется существование экземпляра запрашиваемой сущности, возможно, сущность уже загружена из базы данных. Если загружена, метод Create() возвратить ссылку на её экземпляр, иначе экземпляр, ассоциируемый с запрашиваемой сущностью, будет сначала создан и потом уже возвращена ссылка на него.

    После получения сущности, её можно полноценно использовать, например, обратиться к её классу и узнать системное имя.

    echo $obj->getP('class')->getA('sys_name');

    Обратите внимание, загруженная сущность – это класс, но работа выполняется с ним как с объектом. Сущность загружается из БД по требованию, то есть реальное обращение к базе данных происходит только при первом обращении к свойствам или атрибутам сущности, более того, загружаются только те свойства (сущности с которыми выполнена связь), которые используются.

    Возможно, вы задались вопросом, нельзя ли укоротить конструкцию для доступа к свойствам и атрибутом? Магические методы, оптимизация, стилизация – это вопрос времени и решения некоторых тонкостей.

    У объекта имеются свойства (Property) и атрибуты (Attribute). Атрибут – это скалярное значение. Свойство – это связь на другой объект, фактически – объект, с которым выполнена связь. Связь на класс и связь наследования оптимизированы – представлены в БД как атрибуты, но логикой модуля данных они превращаются в свойства.
    Для обращения к свойствам используется метод getP($name), возвращающий объект, с которым установлена связь. Можно обратиться к самой связи с помощью метода getL($name) – возвратится объект связи.

    В приведенном примере выполняется обращение к классу, но связь с классом не реализуется объектом (так как оптимизирована), поэтому обращение к связи на класс бессмысленно – объекта-связи нет. Метод getA($name) используется для чтения значения атрибута по его имени.

    Загрузка сущности автоматически инициируется при первом обращении к любому из её атрибутов или свойству. Загрузка автоматически выполняется методом Load(). Для загрузки сущности определяется её класс, определяется иерархия наследования классов. По классам определяются таблицы, из которых загружаются атрибуты сущности. Для загрузки свойств достаточно напрямую обратиться к таблице связей и загрузить все связи, у которых атрибут «primary» равен идентификатору загружаемой сущности. Загружаются только связи. Объекты, на которые ссылаются связи, загружаются по общему принципу – если будут использоваться их атрибуты или свойства.

    Создание сущности


    Для примера, создадим объект класса «id». Объект будет иметь только идентификатор и связь на класс, которым определяется.

    $new = Object::Create();
    $new->setP('class', Object::Create(1));
    $new->Save();
    Или сокращенно:
    $new = Object::Create(null, Object::Create(1));
    $new->Save();

    Всё очень просто: создается пустой экземпляр сущности, создается связь на класс с идентификатором 1 и выполняется сохранение. После этого в таблице «id» появляется новая запись. Атрибут-идентификатор сущности создаётся автоматически автоинкрементом ключевого поля таблицы «id».

    Создание класса происходит точно также. Для примера создадим пробный класс с именем «my» и определением атрибута «value»:

    $new = Object::Create();
    $new->setP('class', Object::Create(2)); // Создаём класс, поэтому связь с #2
    // В зависимости от класса создаваемой сущности, определяются значения
    // атрибутов и свойств, (поэтому связь с классом определяется первой)
    $new->setP('extend', Object::Create(1)); // Наследуем базовый класс
    $new->setA('sys_name', 'my'); // Системное имя класса
    $new->setA('final', 0);  // Можно наследовать
    // Описание единственного атрибута
    $new->setA_cl('value', array('type'=>'varchar', 'max'=>255)); // строковый атрибут
    $new->Save();

    Определение атрибута сводится к указанию параметров поля таблицы БД. После сохранения, автоматически будет создана таблица «my» с полями «id» и «value» и добавлена запись в таблице «id» и «class», ассоциируемая с сущностью-классом «my»

    Описание атрибута выполняется методом setA_cl($name, $params). Ничего сложного, просто указывается имя атрибута и параметры, соответствующие параметрам поля таблицы БД.

    Если нужно определить свойство, тогда методом setP_cl($name, $class) создается связь с именем $name на сущность-класс $class. При этом можно уточнить атрибуты связи, обратившись методом getL_cl($name) к автоматически созданной сущности-связи.

    Теперь можно создать объект класса «my». Допустим, созданный класс «my» получил идентификатор 5.

    $new_obj = Object::Create();<br>$new_obj->setP('class', Object::Create(5)); <br>$new_obj->setA('value', 'Тра ля ля'); // Установка значения атрибута<br>$new_obj->Save();<br>

    Удаление сущности


    Удалить сущность ещё проще:

    $obj = Object::Create(6);
    $obj->Delete();

    Сначала создается экземпляр удаляемой сущности (сущность не загружается из БД), потом вызывается
    метод Delete().

    При удалении сущности, автоматически удаляются все её связи. Если связь является вида «состоять» (kind=0), то будет удалена и сущность, на которую ссылается связь. Удалить сущность, являющеюся составной частью другой сущности (вид связи = «состоять»), не получится. Также не получится удалить класс, если он наследуется другим классом или имеются сущности этого класса.

    Текущая версия CMS Boolive в свободном доступе. Информация на сайте
    Для тестирования приведенного в статье кода, вставляйте его в файл
    /modules/page/templates/view/root.php

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

    Моделирование содержимого


    Приступим к моделированию содержимого сайта. Создадим несколько простых классов для представления строк и чисел: string, long_string, text, integer, double. Каждый класс определяет один атрибут «value» для значений. Класс «string» — для представления коротких строк размером не более 255 символов. «long_string» — для представления длинных срок, ограничения по длине не более 20486 символов (20Кбайт). Класс «text» — для очень длинных строк размером до 65535 символов включительно (64Кбайт). «integer» – для целых знаковых чисел разрядностью 32 бит (-2147483648… +2147483647). «double» — для действительных чисел (-1.7976931348623157e+308… 1.7976931348623157e+308). В представление значений других типов необходимости пока нет.

    Все пять новых класса наследуют базовый класс «id». Определяются же они классом «class», от чего они и являются классами. На диаграмме (Рис. 1) у сущностей отображены не все атрибуты – идентификатор дублируется в заголовке прямоугольника сущности, там же указаны класс сущности его системным именем («class») и значение атрибута «sys_name» курсивом зеленым цветом.
    PHP код для создания 5 классов представляющих строки и числа.

    Основные классы для представления строк и чисел.
    Рис 1. Основные классы для представления строк и чисел.

    Теперь можно создавать объекты любого из новых классов. Но мы займемся другим. Добавим определение двух свойств у класса «class» и «link». Определяя два свойства в классе «class», мы тем самым добавляем соответствующие свойства всем классам: «id», «class», «link», «string» и остальным, так как они являются объектами класса «class». Также и для класса связей «link» – у всех объектов-связей появятся свойства вдобавок к существующим атрибутам.

    Итак, добавляем определение, для этого создаем связь между классом «class» и классом «string» (Рис 2. #9). У связи устанавливаем значения атрибутов: вид связи («kind»=0), мощность («size»=1), признак обязательного существования определяемого свойства у объектов («is_mandat»=1). Остальные атрибуты инициализируются автоматически. Создаются две связи, одна на класс «string» другая на класс «long_string».
    PHP код для определения свойств в классе «class»

    После у каждого класса будет свойство «name» и «descript». Первое свойство для именования класса на русском языке, второе для описания назначения класса. Фактически, мы наделили объектную модели возможностью самой себя документировать. Для примера на сайте будет ссылка «создать Новость» при этом само слово «Новость», да ещё и описание, что такое новость или, что реально будет создано, будет осмысленно взято из БД, а не прописано в шаблоне оформления или подгружено откуда-то со стороны.

    Теперь добавим определение двух свойств в классе «link». Эти свойства будут необязательны для связей (атрибут «is_mandat» = 0). Первое свойство с системным именем «label» будет использоваться для именования связи на естественном языке, второе свойство для пояснения связи (свойства объекта, владеющего связью). Рис 2. #11, #12.
    PHP код для определения свойств в классе «links»

    Созданные определения свойств для связей имеют такой же смысл, что свойства для классов. Благодаря ним объектная модель, словно сама будет говорить: «новость имеет заголовок». Объектная модель теперь способна сама себя описывать и способствовать созданию удобного пользовательского интерфейса.

    Теперь необходимо у классов и связей создать свойства, наличие которых только что было определено. Начнем со связей. Так как свойства для связей определены необязательными, ограничимся лишь именованием связей у классов «class» и «link». Рис 2. #13 – #20
    РHP код для добавления свойств «label» у связей, определяющих свойства классов и связей

    Теперь разберемся с классами. Всего уже 8 классов. Так как свойства для классов определены обязательными, значит, их необходимо создать у каждого класса. Фактически добавляется нормальное название и описание каждому классу. Рис 2.
    РHP код для добавления свойств «name» и «descript» у всех классов

    Основные классы данных и их описание
    Рис 2. Основные классы данных и их описание.

    Как видно по диаграмме (Рис 2), у каждого класса есть название и описание на русском языке. Все связи между сущностями являются объектами, что тоже видно по диаграмме. Объекты строк схематично упрощены, текст в нутрии прямоугольника – это значение единственного их атрибута «value».

    Теперь ближе к теме содержимого сайта. Создадим для примера четыре класса. Первый из них – класс «content» (Материал) со свойствами «head» (Заголовок) и «text» (Текст). Это будет самый простой тип материала для сайта, который подойдет для новостей или статей. Класс «content» наследуется от базового класса «id», а в качестве свойств используются классы «string» и «text». Рис 3. #52 – #63
    PHP код для создания класса Материал

    Продемонстрируем возможности наследования. Создадим класс комментария «comment» наследуя его от класса «content», от чего он уже будут иметь определение свойства заголовок и текст. Для комментария посчитаем их достаточными и ничего нового в нем определять не будем. Рис 3. #64 – #68.
    PHP код для создания класса Комментраий

    Для категоризации материала сайта создадим класс категории «category». Класс «category» наследует базовый класс «id», поэтому у него нет ещё определений свойств. Для категории необходимо название и его пояснение – всё те же свойства с подобным назначением. Особенностью категорий является их иерархичная структура. Чтобы можно было создавать иерархии из категорий, у каждой категории должна быть связь на родительскую категорию. Эту возможность обеспечивает свойство «parent», в определении оно связывает класс «category» с самим собой, что указывает: родитель для категории является категорией. Рис 3. #69 – #82.
    PHP код для создания класса Категория

    И последний класс, который будет нами создан – класс новостей «news». Этот класс наследует класс «content» и добавляет новые определения свойства «comments» (Комментарии) и «category» (Категория). Свойство «comments» множественное, потому что у новости может быть много комментариев. Рис 3. #83 – #90.
    PHP код для создания класса Новость

    Классы матариала и его категоризации
    Рис 3. Классы матариала и его категоризации

    Все необходимые классы созданы. В рабочей CMS конечно будет множество других классов и не только для представления содержимого. Сейчас цель – продемонстрировать работу модуля Data и возможностей, предоставляемых им в управлении данными.

    Создадим, наконец, несколько объектов содержимого. Три категории, две новости и два комментария, принадлежащих к одной новости. Вторая новость без комментариев. На диаграмме хорошо видны созданные объекты и их составные свойства и свойства вида «использовать». Рис 4.
    PHP код для создания трех категорий, двух новостей и двух комментариев для первой новости

    Три категории, две новости и два комментария
    Рис 4. Три категории, две новости и два комментария.

    Это только пример объектной модели содержимого. В виде объектов данных можно представить любой элемент сайта: модули, блоки, пользователей, группы, действия и права на них – возможности фантастические.

    Теперь возникает вопрос, как с этим всем работать? Как, например, получить список новостей? А как насчет условий, например новости определенной категории? Все эти функциональные возможности уже реализованы. В начале статьи были упомянуты классы Query и Cond*. С помощью них осуществляется поиск сущностей. Об этом будет рассказано в продолжение статьи – в третьей части.

    Продолжение: Модель данных. Часть 3
    Сайт проекта: boolive.ru
    Поделиться публикацией

    Комментарии 53

      0
      Как всегда сразу радую глаз схемы. :)
        +1
        Очень похоже на подход который использован в сервисе структур (сервис управления базой данных через типы и объекты): hivext.ru/index.php/Структуры

        А ниже пример на Javascript, хотя можно на любом языке работать с сервисом.
        hivext.ru/index.php/Javascript.Объекты
          +1
          Как-то это все слишком сложно получается. До недавнего времени тоже изобретал свой велосипед. Понял, что даже если и допишу, слишко много потом допиливать при нестандартных задачах. На днях решил остановиться на Yii с его реализацией ActiveRecord. Также присматривался к реализации в Limbo, но мне структура кода не очень приглянулась.
            0
            Прошу прощения, опечатка, в Limb.
              +1
              раз уж смотрели лимб — может посмотрите и у нас? :-) (ссылка в профиле)
                0
                C удовольствием, но ссылку так и не нашел в профиле.
                  0
                    0
                    Бегло ознакомился, в целом неплохо, только имхо можно упростить описание связей many to many. Ну и имхо зря у коллекицй добавление через [] блокируется. Мелочь, а приятно.
                      0
                      пока не до arrayAccess особо — разгар переезда на новый орм %)
            +3
            В чем такие схемы ресуются?
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                ответе на мой ответ… ))

                А если серьезно то автор говорит что рисует все руками во флеше

                p.s.
                смотри комментарий ниже
                0
                Вовка уже сто раз отвечал на этот вопрос: в обычном векторном редакторе.
                Если я не ошибаюсь, он использует флеш.
                –1
                тоже интерсно узанть, статью еще не читал. но схемы радуют глаз
                  +2
                  Вы новички? )) в каждой статье спрашивают, потом ещё и на сайте… — руками во флеше
                    +1
                    Хотелось бы тогда попросить в будущем написать статьи по рисованию красивых диаграмм. Наверняка ведь есть какие-то хитрости, ибо столько нарисовать в единообразной форме и так аккуратно не так-то просто голыми руками.
                      +1
                      А у тебя наверное есть уже какаято подборта объектов, цветов во флеше? поделишся файликом .flа?
                        +1
                        тут народ проявляет больший интерес к диаграмма чем к архитектуре системы :).
                        Чем-то напоминает ситуацию когда небольшой драгоценный камень вставляют в толстые и тяжелые изделия из драг метала. Получается из-за массы и блеска оправы камня то и невидно…
                        Предлагаю вам отложить разработку CMS и начать разрабатывать флеш-диаграмы :))
                        0
                        Совсем не радуют. Нихрена не понятно, даже разбираться не стал. Такое впечатление, что человек при составлении схем пользовался недавней статьёй про презентации «Как заставить слушателей почувствовать себя идиотами». Кто ясно мыслит, тот ясно излагает.
                          0
                          В первой части есть объяснение диаграммы
                            0
                            Всегда думал что диаграммы служат для наглядного пояснения текста, тут оказывается наоборот, пояснять нужно сами диаграммы. Доводилось видеть схемы много проще этих для куда более сложных систем.
                              0
                              вы когда первый раз увидели uml диаграммы, они вам сразу были понятны и все поясняли??? Мне нужно было найти вариант отображения сущностей одновременно со спецификой класса и объекта и мною было сделано пояснение выбранного варианта в первой части статьи…
                            0
                            Зря минисуете его :) Уже вторая диаграма из разряда — убейте меня тапком.

                            P.S. Может стоит посмотреть в сторону генераторов диаграмм классов в VS или Eclipse?
                          +4
                          Когда начальство настояло на использовании Друпала для создания новостной ленты — я офигел несколько опешил от используемого количества таблиц (это для новостей-то). Чувствуется, здесь будет такая же болезнь, помноженная на бесконечные привязки всего ко всему. Под мало-мальски значимой нагрузкой ваше решение упадет.
                            +3
                            еще раз убеждаюсь что об одном и том же люди думают в одно и тоже время но в разных точках Земли.
                            мы также используем ORM в нашем сервисе структур данных, но используя для этого Hibenate. Наша реализация запрограммирована на Java и немного сложнее на стороне сервера при создании своих типов, но зато более гибка в последующем при работе с объектами конкретного типа(-ов). Мапинг обьектов осуществляется на основе динамически сгенерированых классов с последующей их загрузкой в runtime. Классы генерируются соответственно на основе данных предоставленых юзером о типе объекта. Для запроса, поиска, удаления объектов используются JSON или SQL подобный синтаксис, который на сервере трансформируется в Hibenate Criteria. Также реализована Lazy («ленивая», по требованию) загрузка свойств объектов.
                            С учетом того что мы разрабатываем на разных ЯП, рад что кто-то реализовывает чем-то схожую с нами архитектуру работы с объектами.

                            P.s.: диаграммки чудо! в чем это они сгенерированы?
                              0
                              Hibenate — это всё же немного другого класса инструмент. Там есть кэш первого уровня, кэш второго уровня, различные виды Lazy-инициализации, различные способы задания маппинга, различные способы отображения иерархий объектов в модель, свой язык запросов…

                              Сравнивать Hibernate с тем, что описано в статье, это то же самое что сравнивать современный многоцелевой истребитель с самолетами первого десятилетия после братьев Райт — да, вторые тоже летают, но им еще предстоит долгий путь развития до того уровня, когда они будут столь же эффективны, как и первые.
                                0
                                ну почему же, всегда можно сравнивать что с чем-то просто, главное определить критерии сравнения. В данном случае я хотел подчеркнуть схожесть применения [b]динамического[/b] мапинга объектов в таблицы БД.
                                Никто и не спорит что реализация такого мапинга у Hibernate на несколько порядков выше. А если учесть что это дело совместно используется со Spring (Transactional, DAO, прочее) + Invocation + Reflection — тогда становится очевидным возможный уровень реализации…
                              +2
                              Гибкость — это, конечно, хорошо. Мне подобная идея приходила в свое время. Но неприятны два момента:
                              1 — производительность в работе с БД. у меня возникают большие сомнения, хотя я и не знаток в этой области.
                              2 — красота и изящество реализации этого на ПХП. выглядит это, простите, не очень. слишком многабукаф.
                                0
                                всё верно)
                                +2
                                А я из принципа не буду спрашивать о редакторе диаграммок — читал предыдущую статью ;)

                                1. Названия методов (setA, setP и т.д.) ни о чем не говорят, как-то некрасиво.
                                2. Если уж Вы в методе Create проверяете на наличие уже созданного объекта, может переименовать его в Instance?

                                А вообще как-то все сложновато выглядит, если для базовых типов данных надо создавать классы…
                                  0
                                  Да, и еще — если Вы передаете в Create() какие-то числа, заранее привязанные к определенным типам объектов, наверное лучше их объявить как константы (типа BOO_ID, BOO_STRING и т.д.), так читается легче.
                                    +1
                                    Топикстартер сильно идеализирует универсальность и KISS'ом тут даже не пахнет.
                                      0
                                      A — Attribute
                                      P — Property
                                      L — Link
                                      set/get
                                        +1
                                        setAttr()
                                        setProp()
                                        setLink()
                                        всего на три символа длиннее, а насколько читабельнее! Так ведь можно и вместо set/get писать s/g
                                          +1
                                          смысл орм — скрывать слой хранения данных от программного кода.
                                          конкретной спецификацией A/P/L вы этот принцип нарушаете.
                                          0
                                          Почему же ничего не говорит, я сразу бросил статью читать и начал любоваться диаграмами, они в статье самое ценное. Опыт подсказывает, что для нормальной реализации ORM нужен нехилый опыт, а стиль указывает на его отсутствие.
                                          –3
                                          Похоже на интерпретатор Ruby, реализуемый на PHP
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              0
                                              Я пошел совершенно обратным путём, которым сейчас пользуюсь.
                                              У меня создаваемая и используемая структура полностью зависит от структуры в SQL БД.
                                              То есть класс генерится тоже от БД, но от полей, заданных в SQL:
                                              class Path extends CDBItem{
                                                function lenght(){
                                                  return sqrt($this->width*$this->width+$this->height*$this->height);
                                                }
                                              }
                                                
                                              class DBPath extends CDataBase{
                                                protected $objectname="Path";
                                                
                                                function get_byStation($id){
                                                  return $this->get_bySelect()->where("stationID=? ORDER BY point",$id);
                                                }
                                              }

                                              $StationBusDB=new DBPath($sql->table('station_bus'));

                                              //Простое отображение БД
                                              $SearchDB=new CDataBase($sql->table('search'));


                                              За материал спасибо, всеравно интерестно почитать.
                                                0
                                                Ваш вариант, кстати проще и технологичнее чем у автора :)

                                                Нет смысла создавать механизм для записи конфигурации моделей в БД, если тебе все равно где-то придется эту конфигурацию задавать. Лучше это сделать 1 раз и в одном месте. Т.е. нужен только механизм чтения.
                                                +1
                                                Ждем третью часть ,-)
                                                  +2
                                                  О боже!..
                                                  $class = Object::Create();
                                                  $class->setP('class', Object::Create(2)); // определение класса для объекта (создание объекта класса #2) — создается класс
                                                  $class->setP('extend', Object::Create(53)); // наследует простой материал
                                                  $class->setA('sys_name', 'news'); //системное имя класса
                                                  $class->setA('final',0); // можно наследовать
                                                  $name = Object::Create(null, 4); // создание объекта класса #4 (создание строки)
                                                  $name->setA('value','Новость');
                                                  $class->setP('name', $name); // свойство названия класса
                                                  Вы правда думаете, что такой код гибче и проще в поддержке?
                                                    +1
                                                    а его не нада писать)) это в статье приведен пример РУЧНОГО создания классов и объектов, на самом деле будет создан вебинтерфейс и контроллер, который всем этим будет сам заниматься.

                                                    И тут нет ничего сложного: связь на класс, на наследуемый класс, название класса… и связь на объект-строку Новость… все понятно) все осмысленно
                                                      0
                                                      Это кошмар!
                                                        0
                                                        Отлично! спасибо за статью и проделанную работу.
                                                        Я просто мечтаю, что бы появились семантические базы данных (или обьектно ориентированные), но только в промышленном и общедоступном виде…
                                                          0
                                                          схемы в приятной пастельной палитре, спасибо! я сохранил и сделал стильные обои для рабстола.
                                                          а текст не осилил…
                                                            0
                                                            Как многие заметили — схемы получились классные. Может вам создать продукт который будет такие вот схемы делать?
                                                              0
                                                              да вот думаю тоже)))
                                                              +1
                                                              Не стану оригиналом, если скажу что вся эта конструкция будет безбожно тормозной. Видел несколько лет назад реализацию CMS в таком духе от одной из студий. Там всё было попроще. Общая таблица с id, parent_id, class_id. Таблица с описанием полей: name, ru_name, свойства какие-то ещё. И непосредственно таблицы под каждый класс. Соответственно сначала по id из главной таблицы дёргался класс. Потом если надо описание полей. Если не надо — сразу информация из таблицы класса.

                                                              К чему я всё это? На очень средненьких проектах на обычном хостинге эта штука начинала лагать и тормозить, хотя и держалась. Когда все запросы проходят через одну таблицу — это не есть хорошо. Сейчас конечно и машины посильнее и хостинг подешевле. Но у вас структура избыточно раздута. Это будет CMS ориентированная на разработчика, а не на пользователя. Наверное здорово, что можно будет за 15 минут собрать хомячка, но на проекты покрупнее этого монстра врят ли кто решится поставить. А для CMS это верная смерть.

                                                              С другой стороны, если всё это пишется для собственного развития, то задумка хорошая.
                                                                0
                                                                Согласен, это так-то все видят — за гибкость производительностью платить)).

                                                                В данной ситуации — это все равно что поиск лучшего хода в шахматной игре полным перебором, но ведь сама цель сделать компьютер победителем в шахматах у человека не отвергается, а предлагаются и реализуются оптимизированные алгоритмы не требующие полного перебора. На подобии можно пойти и в достижении гибкости cms — новые подходы кэширования, оптимизация загрузки из БД созданием каких-то расчетных таблиц, ну придумать есть что))
                                                                0
                                                                Не стоит привязывать думаю к языку модель данных! Модель данных гораздо сложнее и управлять всеми преимуществами из языка есть не очень хорошая задача которую в основоном не получится реализовать. Лучше как тут уже предлагали читать то что уже есть и строить модель отталкиваясь этой служебной информацией. А эту струтктуру можно и нормализовать в другом виде также в БД :-)
                                                                  0
                                                                  К какому языку? языку программирования? Если про язык программрования, то тут как раз модель данных независима от языка программирования
                                                                    0
                                                                    Да сам данные согласен но реализация немного сложноватая, мне так кажется, так как думаю что ты пытаешься сделать некий образ языка с наследованием и вскими фишечками. Вот если ты возмешь PostgreSQL то там свзяи (FOreign Keys) тоже хранятся в служебной информации можно ими пользоватся. Я к тому что нужно свести к минимум изобретения еще какой-то прослойки это приведет к дополнительным ошибкам.

                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.