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

Как всегда сразу радую глаз схемы. :)

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

А ниже пример на Javascript, хотя можно на любом языке работать с сервисом.
hivext.ru/index.php/Javascript.Объекты

Как-то это все слишком сложно получается. До недавнего времени тоже изобретал свой велосипед. Понял, что даже если и допишу, слишко много потом допиливать при нестандартных задачах. На днях решил остановиться на Yii с его реализацией ActiveRecord. Также присматривался к реализации в Limbo, но мне структура кода не очень приглянулась.

В чем такие схемы ресуются?

Когда начальство настояло на использовании Друпала для создания новостной ленты — я офигел несколько опешил от используемого количества таблиц (это для новостей-то). Чувствуется, здесь будет такая же болезнь, помноженная на бесконечные привязки всего ко всему. Под мало-мальски значимой нагрузкой ваше решение упадет.

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

P.s.: диаграммки чудо! в чем это они сгенерированы?

Гибкость — это, конечно, хорошо. Мне подобная идея приходила в свое время. Но неприятны два момента:
1 — производительность в работе с БД. у меня возникают большие сомнения, хотя я и не знаток в этой области.
2 — красота и изящество реализации этого на ПХП. выглядит это, простите, не очень. слишком многабукаф.

А я из принципа не буду спрашивать о редакторе диаграммок — читал предыдущую статью ;)

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

А вообще как-то все сложновато выглядит, если для базовых типов данных надо создавать классы…

Я пошел совершенно обратным путём, которым сейчас пользуюсь.
У меня создаваемая и используемая структура полностью зависит от структуры в 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'));

За материал спасибо, всеравно интерестно почитать.

Ждем третью часть ,-)

О боже!..

$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); // свойство названия класса

Вы правда думаете, что такой код гибче и проще в поддержке?

а его не нада писать)) это в статье приведен пример РУЧНОГО создания классов и объектов, на самом деле будет создан вебинтерфейс и контроллер, который всем этим будет сам заниматься.

И тут нет ничего сложного: связь на класс, на наследуемый класс, название класса… и связь на объект-строку Новость… все понятно) все осмысленно

Это кошмар!

Отлично! спасибо за статью и проделанную работу.
Я просто мечтаю, что бы появились семантические базы данных (или обьектно ориентированные), но только в промышленном и общедоступном виде…

схемы в приятной пастельной палитре, спасибо! я сохранил и сделал стильные обои для рабстола.
а текст не осилил…

Как многие заметили — схемы получились классные. Может вам создать продукт который будет такие вот схемы делать?

Не стану оригиналом, если скажу что вся эта конструкция будет безбожно тормозной. Видел несколько лет назад реализацию CMS в таком духе от одной из студий. Там всё было попроще. Общая таблица с id, parent_id, class_id. Таблица с описанием полей: name, ru_name, свойства какие-то ещё. И непосредственно таблицы под каждый класс. Соответственно сначала по id из главной таблицы дёргался класс. Потом если надо описание полей. Если не надо — сразу информация из таблицы класса.

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

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

Не стоит привязывать думаю к языку модель данных! Модель данных гораздо сложнее и управлять всеми преимуществами из языка есть не очень хорошая задача которую в основоном не получится реализовать. Лучше как тут уже предлагали читать то что уже есть и строить модель отталкиваясь этой служебной информацией. А эту струтктуру можно и нормализовать в другом виде также в БД :-)