Это статья не про готовую технологию, а для разработчиков технологий. Когда будет релиз инструмента для разработки прикладных систем, то я его опишу простым языком. Там даже про уровни абстракции ничего не будет сказано, хочется сделать инструмент, приближенный к пользователю и с использованием популярной или бизнес- лексики.
С такими темпами мы переучим Хабр использовать научную лексику и стиль статей)
Именно так, обобщение и повышение абстракции модели даже на один уровень, позволяют охватить в 10 раз больше различных предметных областей, отличающихся спецификой. А разработка информационных систем должна сводиться не к количественной эскалации использования паттернов, а к двум параллельным процессам: абстрагирование и индивидуализация. Где абстрагирование — это повышение абстракции, а индивидуалтзация, это реализация специфического функционала уже в рамках абстрактной модели более высокого порядка.
Основная идея такая:
— берем готовую структуру реляционной базы и автоматически экстрактим из нее метаданные
— доописываем метаданные, которых не хватает, чтобы построить полноценную метамодель
— таким образом имеем два и более слоя абстракции в базе
— если нужно менять структуру базы, то имеем специальную админку, где управляем метаданными, а структура в базе модифицируется уже автоматом
— при передаче данных между системами, передаем данные + часть метамодели, включая струкутру, шаблоны, интерфейсы, поведение
— часто используем динамическую интерпретацию метамодели, в частности, для динамического построения интерфейсов пользователя и гибкого сетевого взаимодействия
О! У нас в команде уже последние 10 лет все разрабатывается с применением элементов метамодели, но полной реализации пока нет, вот готовим фреймворк в данный момент, будет оупен-соурсным, дам на ознакомление )
В параметрических базах данных все атрибуты сущностей сливают или в одну таблицу или делают по таблице на каждый тип данных. Но это приводит к тому, что таблица-хранилище разрастается, его невозможно эффективно индексировать (в индекс попадают лишние данные) и нарушается реляционный принцип. По сути — все преимущества реляционного подходя теряются, запросы красиво строить уже нельзя, толпы JOIN-ов. Такие БД как раз получаются, как один из видов решения проблемы стыковки объектно-ориентированного программирования и реляционного подхода в СУБД. Но эффективны они только когда данных мало. Если мы имеем миллионы и сотни миллионов записей в таблицах, то тут уже ООП должно прогнуться под СУБД, вплоть до частичного отказа от принципов объектного подхода.
В конце статьи прикрепил еще схему, где показаны все аспекты моделирования сущностей с использованием метамоделей, которые удалось собрать за последние 10 лет практического применения этих методов. В нижней строке белым помечены блоки, которые реализованы в СУБД, а серым, которых в СУБД нехватает для построения полноценных приложений на основе динамически-интерпретируемых метамоделей.
Каждый слой хранит только свои специфические атрибуты, поэтому у нас получается еще один аспект хранения «группа атрибутов». Группироваться они могут по уровню абстракции, по языку, по периоду валидности, по применению в задачах и еще по многим вещам. Если нам нужно выбрать из базы весь «профиль сущности», то мы делаем несколько независимых SELECT-ов, каждый из них отдает одну или несколько групп. Например экземпляров сущности «Паспорт» может быть несколько для каждого экземпляра «Персона», а вот «личное дело» в отделе кадров одно, а адресов может быть у него много да еще и каждый адрес может быть на нескольких языках. Я думаю JOIN тут не нужны. Лучше всего вынимать это несколькими запросами. Но случаев, когда мы работаем сразу с нескольким уровнями абстракции очень мало, чаще всего прикладная задача требует доступ только к одному аспекту сущности, поэтому SQL-запросы почти не изменятся.
Ну статические предметные области, для которых разработаны известные подходы уже не вызывают сложностей. Более того, классика встречается все реже, т.к. мир меняется более динамично и приходится или руками переделывать все время (что и происходит с общепринятыми подходами) или же придумывать новый тип автоматизации разработки, мне видится, что для БД — это должен быть путь введения метамоделей N-ного уровня (моногомерных абстракций). Это лучше чем реинжениринг всей БД при повышении гибкости.
СУБД не поддерживает многих аспектов метамодели, об этом будет вторая часть статьи. Например, когда у нас есть связь многие-ко-многим мы не можем по Foregn Key метаданным понять, является ли эта связь: Master-Detail или же это связь со справочником, или же с помощью этой связи построена многоязычность одной и той же сущности или связь представляет нечто другое. Всего типов связей, на которые можно разложить один единственный Many-to-Many есть два десятка, и по типу связи можно многое в приложении построить динамически и гибко. Таким образом метамодель в какой-то части повторяет метаданные в СУБД, а в какой-то части их дополнет или переопределяет.
Наверно, я не достаточно раскрыл в статье, почему нагрузка не увеличится (или увеличится несущественно): в базу будут одновременно храниться несколько абстрактных слоев, то есть, классическая структура таблиц не поменяется, просто к ней еще добавится параллельно существующая структура с более высокими абстракциями. То есть, если у нас есть «Сотрудники», «Руководители» и «Персоны» — это три разных слоя. Не всякий сотрудник является руководителем, не всякая персона является сотрудником. Если мы хотим работать с сотрудниками, не заботясь о том, руководители они или исполнители, то в запросах будет фигурировать один уровень абстракции, если нам нужно работать с персонами (то есть со всеми физическими лицами) то в запросах будут таблицы более абстрактного слоя. Поэтому, такую штуку можно навернуть сверху почти на любую структуру БД. Единственные изменения, которые я вношу в нижние слои абстракции, это:
— Во всех таблицах с сущностными будет не отдельный автоинкрементный ID, а сквозной на всю БД
— Все таблицы, ссылающиеся на сущности любого порядка имеют Foreign Key указывающий на одну и ту же таблицу — на таблицу сущностный.
Все же остальные связи в БД не меняются, например у справочников и логов, будут свои автоинкрементные Primary Key.
Советую перед тем, как начинать кодить, сделать себе список задач, корыте будет решать Ваш фреймворк. Вот все что решает он сейчас — это маршрутизация при вызове разных урлов в разные обработчики. Все это же пишется ровно в 3 раза меньше кода без придумывания лишнего. Но задайтесь вопросами посложнее: а можно ли наследовать и переопределять функциональность и от одного обработчика в другой. То есть, чтобы вложенные урлы могли наследовать часть объектов и шаблонов от родительского урла и переопределять, когда это нужно, а потом, в дальнейшем ветвлении урлов, опять возвращаться к функционалу предка (inherited). Наличие Application, возможно продиктовано Вашим Дэлфийским прошлым, так? Тогда Вам не нужно объяснять, что такое inherited, я надеюсь. Потом еще фреймворковые задачи для развития идеи: доступ к базам, сессии и куки, кеширование, и т.д. Я понимаю, что оно у Вас называется «мини-двиг» и это хорошо, но начинайте проектирование систем с требований.
Ну прогресса в современных средствах разработки не видно ни для разработчика, ни для конечного пользователя. Мощности растут, а вот программисту создать или пользователю заполнить простую форму, к примеру, в современных технологиях дольше сейчас, чем это было в консольных программах, когда еще все псевдографикой рисовали и мышку не использовали. Сейчас разработчик, к сожалению, погружен в концептуальные подходы, паттерны и изобретательство, вместо того, чтобы думать только о предметной области, о поставленных задачах. Это говорит о том, что технологии сырые и зеленые еще, «outofthebox» для прикладных приложений нету, а даже если кто-то себя так и позиционирует, то это системы узко специализированные (типа CMS, CRM, SCM, BPM, документооборот и бухгалтерия), а вот именно прикладных платформ нет и не предвидится. Корпорации заняты войнами технологий, а их можно выиграть только внедряя что-то массовое и не оставляя конкурентам надежды на интеграцию и стабильность. Вот и видим только ПО массового потребления, коммуникационное, офисное, системное, работающее с информацией на уровне файлов и не углубляющееся в прикладные базы данных. Развитие прикладного ПО, как мне кажется, вообще пришлось на 1999-2003 годы, после этого оно стало вялотекущим из-за проблем с инструментарием и из-за заложенных во имеющиеся платформы ограничений. Сейчас вот веб-приложения начали понемногу приближаться к формированию устойчивой среды из стандартов, подходов и средств, но она все еще очень разношерстна, и только в 2010 году наконец браузеры дали нам инструментарий который был доступен для оконных приложений (в том же Delphi) еще 10 лет назад.
Проект: телевизионная тема, идея — синхронизировать браузер с телеэкраном, более подробно не могу открыть, к сожалению. Ну сделано то на комете конечно сейчас, но будет постепенно переезжать на сокеты. По многим причинам: комет вводит браузер в состояние загрузки страницы, это много на что влияет, например, во многих браузерах крутится бублик, а чтобы не крутился, нужно делать комет в айфрейме — это уже заплаты. Еще: комет держит на сервере процесс специально под соединение, а у меня десятки тысяч пользователей. Если делать на сокетах, то такого не будет, сервер можно будет сделать на C#, Java, Node.js или др. и это будет один процесс серверный и в нем просто много сокетов открыто, а логика в памяти на них на все один раз развернута (автор тяжко вздыхает, вспоминая о Delphi). Ну и сокеты — это двухсторонний обмен, т.е. и клиент может присылать пакеты и сервер, можно синхронно, а можно и асинхронно, как в моем случае и нужно.
У меня сейчас как раз заканчивается разработка одного приложения, где пользовательским экраном управляет сервер напрямую, то есть, поток команд льется через Comet (Long-pooling) и каждая команда интерпретируется и исполняется джаваскриптом на клиенте. Это как в X-Window System в *nix системах. Красота, в общем. Но я бы с большим удовольствием использовал сокеты, чем Long-pooling. Кстати, как раз в этой задаче стоит вопрос о локальном хранении состояния, т.к. браузеры могут отваливаться и быть в оффлайне (работают по wi-fi и мобильному инету). Тогда конечно поток команд с сервера прекращается, но события происходят, и при восстановлении соединения, нужно все это отдавать серверу. При этом, пользователю будет очень обидно, если события потеряются, а такое сейчас случается, если при пропадании связи он жмет рефреш.
Что дает хранение состояния и сокеты (просто мысли в слух, это все очевидно):
— Приложение может жить без постоянных запросов к серверу достаточно продолжительное время, исполнять свою логику, сохранять в локальную базу и не бояться потери данных;
— Возможность не перегружать страницу;
— Минимизация трафика;
— Возможность синхронизировать экраны у пользователей;
— Возможность управлять экраном браузера с сервера (не заменимо в приложениях групповой работы и играх);
— Возможность работы в оффлайне;
— Возможность транслировать события в две стороны между моделью, развернутой в браузере и в памяти на сервере.
В HTML5 мы получаем SQL-совместимую СУБД, и полноценные сокеты, а на сервере, все к тому идет, что мы получим stale-full серверное приложение на node.js или же просто сохраняющее состояние в memcached или в др. месте. Конечно же, это нужно только для приложений, а stateless остается для сайтов и веб-страниц, там состояние не нужно совершенно. Прикладным же приложениям без машины состояний ни как нельзя, состояние нужно и в UI и в сервере приложений, ну а в БД оно есть само собой.
С такими темпами мы переучим Хабр использовать научную лексику и стиль статей)
— берем готовую структуру реляционной базы и автоматически экстрактим из нее метаданные
— доописываем метаданные, которых не хватает, чтобы построить полноценную метамодель
— таким образом имеем два и более слоя абстракции в базе
— если нужно менять структуру базы, то имеем специальную админку, где управляем метаданными, а структура в базе модифицируется уже автоматом
— при передаче данных между системами, передаем данные + часть метамодели, включая струкутру, шаблоны, интерфейсы, поведение
— часто используем динамическую интерпретацию метамодели, в частности, для динамического построения интерфейсов пользователя и гибкого сетевого взаимодействия
Статья «Потерянная семантика» — blog.meta-systems.com.ua/2009/11/blog-post.html
Статья «Интеграция на уровне вызовов или мета-данных?» — blog.meta-systems.com.ua/2009/10/blog-post_18.html
Статья «Введение мета-уровеня» — blog.meta-systems.com.ua/2011/01/blog-post.html
Статья «Метамодель в задачах интеграции информационных систем» — blog.meta-systems.com.ua/2010/07/blog-post.html
Слайд к докладу «Слой ИС с динамической интерпретацией метаданных» — blog.meta-systems.com.ua/2011/01/blog-post_28.html
И еще ссылки на Хабре:
Статья «Интеграция информационных систем» — habrahabr.ru/blogs/refactoring/117468/
Вот еще пару статей не на Хабре по наработкам моей команды:
blog.meta-systems.com.ua/2011/01/blog-post.html
blog.meta-systems.com.ua/2010/07/blog-post.html
— Во всех таблицах с сущностными будет не отдельный автоинкрементный ID, а сквозной на всю БД
— Все таблицы, ссылающиеся на сущности любого порядка имеют Foreign Key указывающий на одну и ту же таблицу — на таблицу сущностный.
Все же остальные связи в БД не меняются, например у справочников и логов, будут свои автоинкрементные Primary Key.
— Приложение может жить без постоянных запросов к серверу достаточно продолжительное время, исполнять свою логику, сохранять в локальную базу и не бояться потери данных;
— Возможность не перегружать страницу;
— Минимизация трафика;
— Возможность синхронизировать экраны у пользователей;
— Возможность управлять экраном браузера с сервера (не заменимо в приложениях групповой работы и играх);
— Возможность работы в оффлайне;
— Возможность транслировать события в две стороны между моделью, развернутой в браузере и в памяти на сервере.