Архитектура предметной области в CMF/CMS системах

    Практически любая информационная система характеризуется наличием системы хранения и оперирования данными. Возьмем, к примеру, обычные веб-сайты. Для их создания обычно используются какие-либо готовые системы (фреймворки или уже готовые CMS), в которых изначально уже заложена какая-то концепция по работе с данными, установившаяся предметная область. Обычно, если разработчик хочется добавить на сайте раздел новостей, он добавляет в интерфейсе CMS компонент, информационный блок, шаблон и т.п. Суть всех этих конструкций одна — создать сущность в БД для хранения (либо каком-то ином хранилище). В итоге имеется реляционная база данных и, зачастую, какой-то объектно-ориентированный обвес, реализующий связку объект-атрибуты-свойства-методы — реализуется предметная область.

    Ниже пойдет речь об одном из вариантов архитектуры предметной области. Статья базируется на опыте работы в компании ADV, которая применяет подобные методы в разработке веб-проектов. Сложность изложенного материала позволяет понять его не только разработчикам ПО, но и веб-мастерам, которым надо периодически дорабатывать существующие веб-проекты, добавляя в них новые данные.

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

    Представьте себе идеальное приложение, в котором все строится на отлаженной предметной области. Её архитектор (обычно, специалист по каким-либо системам хранения данных) заранее знает будущее приложение и создает хранилище для него по такому принципу, что покрывает 2 из 3-х уровней разработки приложения: уровень хранения и уровень алгоритмов. Дальнейшее создание функционала веб-разработчиком является лишь вопросом бизнес-задачи (вывести все сообщения блога, выбрать все комментарии к текущему сообщению блога и т.п.).

    А разработчику не очень важно знать, как именно организована структура хранения данных на уровне SQL (структура для хранения данных реализована в виде самих данных, реализована стандартными средствами СУБД или смешана). Он оперирует понятиями объект-атрибут. Предметную область в этом случае можно представить графом. Помимо стандартных характеристик объекта (атрибуты (информация), связи) у терминологического поля имеются:
    1. можно организовывать не только связи, но и взаимодействия (триггеры);
    2. маршруты графа (замкнутые, незамкнутые, часто меняются);
    3. отказ от необходимости знать, как выглядят SQL-таблицы на самом деле;
    4. методы (добавить пользователя, отправка письма по почте, а в другой объект что-то добавить).


    Объектная модель


    Объектная модель должна позволять выбрать множество A по известным параметрам B: A(B). Вот несколько практических примеров:
    • список пользователей, у которых возраст > 20: user(user.age>20);
    • список подарков у пользователей с возрастом более 20: gifts(user.age>20).

    В чем особенность этой модели? Разработчику необязательно знать, как связаны объекты «Пользователь» и «Подарок». Ему достаточно описать требуемую бизнес-логику в каком-то виде (API, предоставляемый системой), а сервер сам построит необходимые связи и выдаст нужный результат.

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

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

    Рассмотрим пример, наша предметная область изображена в виде графа.

    image


    На графе описывается ситуация с сотовой связью: оператор — регион — тариф — симкарта(номер) — контракт — телефон — брэнд — человек — где прописан. Пример запроса:
    • регион(человек.возраст>20, brand=Nokia);
    • регион(человек.возраст>20).


    Связи


    Клиентское приложения отправляет параметры объектов «Человек» и «Brand» на объектный сервер, который по ним должен построить связь и выдать список регионов, в которых проживают такие люди. Как видим из графа, существует несколько вариантов его обхода, чтобы выявить связи. Для вычисления последовательно строится дерево, корнем которого является искомый объект (Регион), а ветками — все последовательно связанные объекты. Построение происходит в несколько итераций от искомого объекта в глубь графа. На нашем примере дерева таких уровней 4. В дереве каждый объект участвует только единожды. После построение на нужных узлах отмечаются выставленные разработчиком параметры, лишние узлы отсекаются. В примере с выборкой региона ветка «Контракт-Оператор» не потребуется, поэтому она не учитывается. А по выставленным «Brand» и «Человек» объектный сервер однозначно сможет определить Регион.

    image


    Итак, мы выяснили, как строятся возможные пути между объектами для вычисления функции A(B). Осталось понять, какой именно маршрут выбирается объектным сервером. Тут все очень просто: маршрут выбирается наиболее короткий на основании весов объектов, в нем участвующих. Логично, что самостоятельный объект имеет наибольший вес, равный 1. Объект-связка имеет вес 1/2. Другие сущности хранилища так же имеют подобные веса.

    Типы объектов


    При проектировании систем, особенно таких, которые впоследствии будут развиваться постепенно, наращивая функционал, всегда существует опасность усложнения и замусоривания базы. В предметной области очень часто модифицируются промежуточные связи, но есть базовая терминологическая область, которая с течением времени не меняется. Меняются связки и вспомогательные объекты. При добавлении нового модуля наиболее эффективно строить его на основании того же физического хранилища данных, но в качестве базовых объектов, общих для всей системы в целом (например, пользователь, город и т.п.), использовать не их сами, а объекты-алиасы. Это самостоятельный объект в объектном сервере, полностью копирующие структуру и данные своего родителя. Однако, в структуре графа это самостоятельные вершины.

    В нашем примере мы не использовали алиасы. Но имеется так называемое кольцо, которое провоцирует объектный сервер на построение связей сразу по нескольким маршрутам. Например, если разработчик захочет выполнить запрос Регион(Человек.возраст>20), то объектный сервер будет вынужден пойти сразу по двум маршрутами, один из которых короткий, а второй более длинный.

    Это, в свою очередь, увеличивает время и ресурсы на выполнение операций. Архитектору БД в процессе проектирования следует максимально избегать образования колец. В этом ему могут помочь объекты-алиасы или особый параметр, которым помечаются объекты, которые являются конечными и не позволяют через себя строить сквозные связи. Так же архитектурой предусмотрены объект-связки, помогающие в устранении связей «многие ко многим».

    Безусловно, алгоритмы объектного сервера не всегда могут наиболее эффективно построить связи, а иногда они строятся вообще не так, как задумывал архитектор. Для принудительного включения или исключения объектов из связи существуют так же специальные параметры. Помимо этого, зачастую бывает необходимо не просто указать наличие того или иного объекта в дереве связей, а более глубоко описать саму сущность связи. В этом случае на помощь приходит инструмент, позволяющий в алгоритм построения дерева вписывать специальные условия на синтаксисе СУБД.

    В зависимости от типа архитектуры возможен вариант, когда хранение и представление данных разное. Т.е. существуют виртуальные объекты, которые не являются точной проекцией каких-то объектов в БД, они вообще могут не иметь своей таблицы в БД. Это несколько шире, чем просто объекты-алиасы. Например, калькулируемый объект, аналог VIEW-сущности в СУБД, который содержит поля, содержимое которых динамически вычисляется на основании полей других объектов того же хранилища.

    Выводы


    Целью статьи являлось показать, что при разработке какой-либо системы управления зачастую лучше задуматься не только о том, какие таблицы будут в БД и как они связаны, а еще и о том, какие инструменты для работы с ними предлагаются. Как на всем этом разработчик веб-приложения может сэкономить время. Подобный подход позволяет строить большие, хорошо масштабируемые структуры данных с индивидуальной настройкой каждого объекта независимо от других. И дело тут не только в том, как красиво обернуть данные, а еще и в том, как упростить обращение к ним.

    Эпилог


    Описанная схема реализована в одном закрытом фреймворке Mozart, используемом компанией ADV вот уже не один год для разработки веб-проектов. В целом, средство вполне оправдывает свое существование, потому что именно при создании веб-сайтов как нельзя кстати упрощается значительная рутинная часть. Помимо этого, новому человеку достаточно легко вникнуть в суть и быстро приступить от обучения к непосредственной разработке проектов.

    В ближайшее время Mozart скорее всего будет опубликован с открытыми исходными кодами под одной из свободных лицензий.
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

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

      +1
      Интересно, действительно ли для всех SQL-конструкций описан мета-язык запросов? Есть ли GROUP, LIMIT, INNER JOIN?
        +3
        Безусловно, не для всех. Надо уметь выбрать золотую середину между потребностями и возможностями. Задача ведь не написать альтернативу SQL.
        0
        Можно вопрос: а в виде чего у вас реализован такой объектный сервис? В виде компонента/отдельной службы/чего-то еще? Включает ли он в себя ORM, или функционал маппинга отделен от сервера объектов?
          +1
          Я бы назвал эту реализацию службой, слушающей определенный порт. ORM имеется и включен в сервер объектов. Задача ORM в данном случае по максимуму избавить веб-разработчика от мыслей о базе данных, зачастую человек вообще не знает, на какой СУБД работает проект. Лишь в особых случаях это приходится вспоминать.
            0
            Забавно :) Т.е. у вас своего рода объектная БД с remote-интерфейсом. А там поддерживается весь CRUD, или это только read-only? Если CRUD, то мне интересно решение вопроса с транзакциями через удаленный интерфейс.
              0
              Эх, облажался немного, произошло недопонимание.
              Да, есть объектная БД, у нее есть внешний интерфейс для работы вспомогательных служб, они действительно через этот интерфейс могут производить CRUD, но это не касается основных приложений, который работают с репозиторием. Они-то как раз работают по вполне обычным интерфейсам языковым, поэтому проблем с транзакциями там нет, как теперь можно понять.
          0
          Можно вопрос: как добавление службы повлияло на производительность системы в целом? Если большая нагрузка, SQL-запросы как-то еще можна оптимизировать, а так у нас получается черный ящик.
          И у вас предусмотрена альтернатива всех возможных запросов, которые можна выполнить с помощью SQL?

          Но идея очень интересная.
            +2
            Схема существует уже много лет, на ней работали проекты совершенно разной нагруженности. Сложности бывают, но ведь мы обсудили лишь часть общей системы. Есть другие части, которые в том числе нацелены на разгрузку мощностей сервера.

            Основная концепция — что простые вещи можно делать простыми средствами. Если становится понятно, что абстракция мешает, то всегда можно реализовать функционал альтернативным способом (благо, MVC придерживаемся). Т.е. к объектному серверу можно обратиться не только через API, но и иными способами, при этом часть алгоритмов, заложенных в объектный сервер просто не буду использоваться. Кроме того, в самом объектном сервере заложены механизмы типа представлений, который иногда тоже позволяют делать хитрые вещи.

            Конкретно вмешаться в запрос при обращении через описанные механизмы нельзя. Можно лишь понять, что данная выборка существенно мешает системе, переписав ее на другую, более простую, добавить индексы на нужные атрибуты (делается так же довольно абстрактно от БД).

            Т.е. «черный ящик» для разработчика существует до тех пор, пока не возникают проблемы и ему не надо с ними разбираться. При этом средства для изучения проблем имеются.
            0
            Насколько я понял, речь идет о каком-то дополнительном уровне абстракции, позволяющем смоделировать модель предметной области, независимую как от «клиентов» (программ и интерфейсов) ее использующих, так и от конкретных способов хранения данных (будь то файлы, БД, веб-сервисы и так далее)?
              0
              В достаточно мере верно сформулировано. Хотя добавить полной независимости от способа хранения не получится, точнее это можно реализовать, но существенной ценой.
                0
                Это само собой. В таком случае то, о чем идет речь — Моделирование Домена и использование практик Domain Driven Design.
                По поводу независимости от способа хранения данных — зависимыми в модели домена остаются только репозитории (DDD Repositories -), которые можно заменить на другие для другого типа источников данных.

                Это хорошо, что все это используется. Считаю это самым грамотным подходом к архитектуре (не вдаваясь в нюансы). Более того, если использовать подходы, основанные на тестировании (TDD), то можно независимо от всего и вся протестировать корректную работу любых бизнес-правил отдельно от приложений, использующих данную модель.

                А вот конкретная реализация — в виде ли отдельного app-сервера или еще каким-то образом — отдельная тема, не относящаяся к DDD напрямую.

                И забавно, что само определение Модели Домена ни разу не проскользнуло в топике :)
                  0
                  Наверное, кому-то бы наличие аббревиатур и терминов облегчило понимание смысла, но кому-то нет. В начале статьи я упомянул о том, что материал для всех кругов разработчиков.

                  Да, есть есть несколько вариантов реализовать предметную область. Вероятно, существующую у нас систему можно охарактеризовать как Domain Model.

                  К тому же зачастую (моё мнение) сложно подогнать какую-то систему под одно описание, потому что в ней чего-то недостаёт, а что-то наоборот присутствует, чего нет в упоминаемом паттерно, методике. Поэтому я описал все просто и понятно словами.
                    0
                    Ясно. Ну я и не говорю, что это плохо или хорошо. Просто хотел понять, это то, о чем я думаю или нет :)
                    0
                    Да, я вот тоже все это с интересом прочитал и сразу про доменное моделирование подумал.
                0
                почему-то мне кажется, что это какой-то overkill для подобной задачи (а это ведь просто подсчёт статистики у вас в примерах, т.е. далеко не самая важная часть работы с данными в типичном веб-приложении), возможно, с другими примерами смотрелось бы интереснее.
                  0
                  Возможно. На что фантазии хватило. Ведь фишка в том, что для подсчета такой статистики, как вы это называли, обычному создателю проекта надо написать всего лишь одну несложную строчку. В ином случае кто-то мог бы написать один SQL-запрос. Я просто привел пример архитектуры в статейке, которая применима для довольно широкого круга задач.
                  0
                  Идея очень интересная, но зачем remote-сервер. Хотелось бы узнать, почему вы не сделали это средствами самого языка?
                    0
                    Как уже написал выше, что ремот-сервер несколько недопоняли.
                    0
                    Я правильно понял, что единственный смысл — спрятать связи между таблицами? Это все что делает объектный сервер?
                      0
                      Спрятать связь? Да, можно спрятать физическую связь, можно создать виртуальную. При этом сервер обладает возможностью анализировать эти связи и выдавать необходимые результаты на сложные запросы без явного указания, как именно эти связи строить. Основная фишка не в объектности, абстрактности, а именно в автоматической связываемости объектов. И это касается не только при запросах на чтение, но и на запись, например, постинг форм, в которых множество объектов содержит свои данные.
                      –1
                      очень напомнило реализацию ORM в django.
                        0
                        Не, не, думаю, ORM — это способ доступа к данным и из представление в особом виде (в объектах языка) и это всего лишь инструмент. А выделение предметной области — это немного другое, я так понял, именно о последнем идет речь.
                          0
                          ну инструмент, на мой взгляд, как раз для облегчения работы с предметной областью.
                          1. определяем сущности предметной области.
                          2. описание этих сущностей на ЯП
                          3. работа с ними.
                          4.…
                          5. PROFIT.

                          Единственное отличие на мой взгляд, это то, что автор предлагает работать без привязки к хранилищу данных, что в принципе достаточно странно, поскольку можно сделать прослойку используя кеш и тем самым решить проблему с нагрузкой на хранилище.
                            0
                            «ну инструмент, на мой взгляд, как раз для облегчения работы с предметной областью.»
                            Это да, но во-первых, инструмент не единственный, а во-вторых не только для работы с предметной областью. Так что делаем вывод, что это разные вещи.

                            И отличий тут можно не искать — это концептуально разные вещи. ORM как раз работает на уровне DAL (доступ к данным) и отвечает за сохраниние и выборку объектов, которые _после этого_ будут использоваться в модели предметной области.

                            При этом модель предметной области может в другой своей части использовать вообще другой источник данных, даже не СУБД, а, к примеру, веб-сервис, и там ORM вообще не будет (в то время как модель предметной области свои данные получать будет).
                              0
                              я и не говорил, что должно обязательно быть СУБД, задача ORM как раз в том, что бы представить данные в форме сущностей и методы для работы с ними.
                              Не вижу принципиальной разницы в хранилище, особенно если вспомнить о DTO.

                              Впрочем мы немного отвлеклись, я не совсем правильно выразил свою мысль которую возникла прочитав этот пост.
                              Я имел ввиду, что то что описывает автор, время от времени приводя реализацию на псевдо-коде, очень сильно мне напомнило, работу с сущностями в django используя родные для неё возможности ORM
                          0
                          Если не сложно, можете привести, как в упоминаемом фреймворке можно получить (синтаксис) данные, как в одном из моих примеров в статье?
                            0
                            посмотрите здесь как реализаванны связи many to many
                            +2
                            для более быстрого примера сделаю копи-паст прямо оттуда:

                            Определение моделей:

                            from django.db import models
                            
                            class Publication(models.Model):
                                title = models.CharField(max_length=30)
                            
                                def __unicode__(self):
                                    return self.title
                            
                                class Meta:
                                    ordering = ('title',)
                            
                            class Article(models.Model):
                                headline = models.CharField(max_length=100)
                                publications = models.ManyToManyField(Publication)
                            
                                def __unicode__(self):
                                    return self.headline
                            
                                class Meta:
                                    ordering = ('headline',)


                            Создание:

                            p1 = Publication(title='The Python Journal')
                            p1.save()
                            
                            a1 = Article(headline='Django lets you build Web apps easily')
                            a1.save


                            Добавление
                            a1.publications.add(p1)


                            Выборка
                            a1.publications.all()


                            Выборка с фильтром
                            Publication.objects.filter(article=a1)
                          +1
                          «В ближайшее время Mozart скорее всего будет опубликован с открытыми исходными кодами под одной из свободных лицензий.»
                          Не забудьте об этом погромче сообщить, пойду еще раз перечетаю Ваш пост.
                            0
                            Само собой разумеется.
                            +2
                            Подход интересен, насколько я понял, вы выделили ORM-интерфейс к базе данных (и к другим хранилищам) в отдельный объектный сервер (под ORM понимаем вообще любые объекты с определенными связями и операции над ними). Но при этом возникает множество вопросов:

                            1. На чем основывалось решение реализовать систему в виде демона, а не как обычный модуль? Практически все крупные компании пошли по второму пути: .Net Entities, Hibernate и т.д.

                            2. Насколько увеличивается латентность запроса? Если до этого приходилось иметь только пул подключений к базе данных, то теперь добавился еще один: к объектному серверу.

                            3. Какой оверхед вносит объектный сервер? Насколько быстро он может построить
                            необходимые запросы для базы данных?

                            4. API объектного сервера проще, чем SQL (иначе, в нем нет смысла). Большинство операций над данными сильно упрощается, но что делать, когда потребуются все возможности SQL? Насколько сложно реализуются именно нетипичные запросы (вложенные, рекурсивные и т.д.)? Возможны ли они вообще?

                            5. Как происходит доступ к вычислениям (Avg, Sum и т.д.)? Допустим, надо получить всех операторов из определенного региона и количество их пользователей.

                            6. Допустим, необходимо получить список людей вместе с телефонами и пропиской. Возможно ли получение объекта с его «детями» за один запрос, указав «выбрать связанные» (select related)? Или придется делать множество маленьких запросов?

                            Вообще, очень интересно было бы посмотреть именно на реализацию. Буду надеяться, исходные коды и правда будут открыты.
                              0
                              1. Переабстрагировался в описании и запутал читателей. Назовем это не сервером, а службой, поэтому никакого процесса-демона нет. Цитата свыше: «Да, есть объектная БД, у нее есть внешний интерфейс для работы вспомогательных служб, они действительно через этот интерфейс могут производить CRUD, но это не касается основных приложений, который работают с репозиторием. Они-то как раз работают по вполне обычным интерфейсам языковым, поэтому проблем с транзакциями там нет, как теперь можно понять.»

                              3. Хотя от понятия сервер мы вроде как избавились, однако этот вопрос актуален в любом случае. Вопрос неоднозначный, поскольку существенно зависит от сложности запроса и объема данных, с которыми оперирует механизм. На практике у нас с этим нет никаких проблем. Обычно совсем другие этапы обработки вносят задержки, нежели построение связей, запросов. Безусловно, не обошлось без кэширования.

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

                              5. Есть несколько способов оперировать такой логикой: на уровне репозитория через «калькулируемые» объекты, атрибуты, связи, на уровне контроллера через API, комбинирование этих методов. Есть отличные идеи, которые именно для таких случаев мы бы хотели реализовать, но нет пока возможности.

                              6. Вы идентифицируете человека и говорите, что с ним хотите взять Телефон и Прописка. Система сама построит связь и вытащить нужные данные в удобочитаемой форме. Возможность сказать «select related» нет, ибо связанных сущностей может быть очень много, сколько уровней взять, все деревно или один слой?.. Если, конечно, хранилище построено логично и такая связь прослеживается.
                                0
                                Спасибо за подробный ответ.
                              0
                              Хороший топик.
                              Вопрос автору: а не пробовали использовать технологию для других приложений (не вебом единым живем)?
                              У меня самого стремительно бежит мысль, чтобы явно выделить отношения предметной области и абстракции из языка программирования, оставив ему только низкоуровневую работу… И показанная здесь идея очень точно соответствует этой задумке. Вот и соображаю, как бы сэкономить на объеме кодинга для диплома )
                                0
                                Все описанное реализовано на Java. Задумка была такая, чтобы сделать систему хранения, которая как самостоятельная единица. В нашей практике с ней работает часть сервлета, отвечающая за обработку веб-запросов (ну или сам сервелат, если более правильно). Ничто не мешает сделать любое другое приложение.

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

                                  Когда появятся практические результаты — постараюсь ознакомить. Вдруг что-нибудь интересное для себя найдете )
                                0
                                Дмитрий, какие цели преследует ADV, публикуя Mozart в открытых исходных кодах под одной из свободных лицензий?
                                  +1
                                  Нам кажется, что наш продукт будет интересен сообществу профессиональных разработчиков. Мы много сил потратили на разработку Mozart, и у нас большие планы по развитию системы. Формат открытых исходных кодов кажется нам наиболее правильным с точки зрения популяризации продукта и построения эффективной системы обратной связи с пользователями.
                                    0
                                    Такой способ популяризации в первую очередь направлен на непосредственных разработчиков. Вы планируете выстроить партнерскую сеть или сообщество пользователей?

                                    И еще: чем вы руководствуетесь при выборе между Mozart'ом и 1С-Битриксом для каждого конкретного проекта?
                                      0
                                      Второй вопрос не по адресу, я лично не принимаю решения.

                                      Планы в какой-то степени большие, но далеко загадывать бы не хотелось, потому что надо будет действовать по обстоятельствам. Я заинтересован в сообществе, которое будет как принимать участие в разработке системы, так и в ее использовании для разработки своих веб-проектов.
                                0
                                На мой взгляд это правильный подход. Я как-то дошел до аналогичной мысли и пошерстил немного интернет в поисках готовых реализаций сего дела.

                                Эта штука боле-менее общепринято называется EAV/CR — «entity-attribute-value with classes and relationships» И не все считают ее хорошей идеей. Иногда EAV приводится в качестве антипаттерна из-за возможных сбоев.

                                Самое раннее описание что я видел — www.interface.ru/fset.asp?Url=/misc/hran_01.htm за 2002 год.

                                Сам хочу обзавестись подобным функционалом для своих проектов. Посуму вопрос — когда можно ждать Mozart? Или может быть кто из хабрапесателей поможет мне в написании своего велосипеда на эту тему?
                                  0
                                  Нет. Мы не практикуем такого. Однажды была идея сделать нечто подобное, даже есть практические работающие варианты.
                                    0
                                    Такого это какого? Если EAV/CR то в топике описано нечто, очень похожее на него.
                                      0
                                      Возможно, я просто не очень вдавался в детали EAV/CR, просто обратил внимание в статье на wikipedia о способе хранения информации, структуре конечных таблиц в БД.
                                        0
                                        А при чем тут структура конечных таблиц? Разве физическое представление данных как-то меняет идею? И если я подбный интерфейс буду использовать для хранения в каком-нибудь оракле вместо постгреса — это сильно изменит идеалогию приложения?
                                  0
                                  Ребят это круть, что вы используете hibernate в своем продукте, но когда я вижу «Документ:: Блок слоя» я понимаю кто единственный пользователь этого продукта. P.S. есть проекты в которых разработчику не до связей которые нагенерил фреймворк и не до названий таблиц…
                                    0
                                    Написал личное сообщение по теме…
                                      0
                                      Целью статьи являлось показать, что при разработке какой-либо системы управления зачастую лучше задуматься не только о том, какие таблицы будут в БД и как они связаны, а еще и о том, какие инструменты для работы с ними предлагаются.
                                      при большом объеме взаимосвязанных объектов, держать в голове все их взаимосвязи так же тяжело как и связи в реляционной БД, не говоря уж о том чтобы задумываться какие там таблицы и связки насоздает ORM, мониторить их нужно, но вот выполнять работу фреймворка, зачем?
                                    0
                                    Еще такое наблюдение: данная система очень напоминает семантическую сеть или, что потенциально ближе, ER-диаграмму (только очень прошу, не надо ее путать с реляционной диаграммой — это очень распространенная ошибка, в том числе в современных средствах проектирования). А зная историю и корни ER-диаграмм, можно сказать, что данная идея является более фундаментальной, чем те же РБД или даже ООП. Отсюда 2 вопроса:
                                    1. Проводили ли вы фундаментальные исследования в этой области? Если да, то можете ли поделиться, если нет, то заинтересованы ли вы в них и планируете ли проводить?
                                    2. Заинтересует ли вас низкоуровневая реализация такой системы? (То есть когда работу семантической сети выполняет отдельное приложение — это обосновывается фундаментальным характером самой идеи, из-за которого реализация в объектах может содержать много лишнего)
                                      0
                                      Зачастую, перед реализацией проекта проектируется сама модель хранения: прямо на бумаге рисуется некое упрощение ER-диаграммы. Зачастую мы это делаем уже на более сложных существующих проектах, чтобы провести ревизию.

                                      Но, боюсь, я не очень озадачивался данными теоретическими вопросами. Мы ведь занимаемся не сколько научной теоретикой, сколько средствами для практического применения. Могу лишь предположить, что наша идея, ее реализация все-таки более ближе к реляционной ее части, потому как в основу хранилища обычно у нас положена реляционная СУБД.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        +1
                                        Зачем же так жёстко =)
                                        1. Я хотел описать некую архитектуру, с помощью которой можно проектировать хранилища данных, и которая позволяет упрощать работу с ними.
                                        2. Я не пытался описать работу какой-то системы с конкретными примерами, как в ней это устроено, как выглядит синтаксис запросов. Да, система есть и она работает. Возможно, в одной из будущих статей я затрону ее API.
                                        3. Почему я должен приводить какие-то отличия? Я сказал, что система, используемая в качестве первоисточника статьи, называется Mozart. И она существует уже более 10 лет, как закрытая система разработки внутри компании. Вы можете привести примеры подобных систем, существующих более 10 лет назад? Да и вообще я не пытался сказать, какая моя система уникальная. Потому что я не знаю всех уже существующих систем, их истории. Я просто констатировал, что такая система есть.
                                        +1
                                        регион(человек.возраст>20)

                                        и как понять, какие же регионы в итоге выбираются:
                                        1. где человеки имеют подключеные симки к региональным тарифам
                                        2. где прописаны человеки
                                        ?
                                        будет выбран самый легкий путь?

                                        ок. допустим, изначально (во время реализации) в графе существовал только первый путь (через тарифы). что происходит с приложением, выполняющим этот запрос, после добавления в БД нового, более «легкого», пути (через прописку, в данном случае)?

                                        так на онтологии похоже. :)
                                          0
                                          и как понять, какие же регионы в итоге выбираются:
                                          1. где человеки имеют подключеные симки к региональным тарифам
                                          2. где прописаны человеки

                                          Я, конечно, не автор, но судя по логике предикатов, будет выбран регион, связанный с человеком непосредственно. Для симки конструкция выглядела б примерно так: регион(симка.человек.возраст > 20)
                                          так на онтологии похоже. :)
                                          они и есть =)
                                            +1
                                            Как описано в статье, выбирается наиболее короткий путь. Так же там написано, что вершины графа могут иметь определенный параметр, запрещающий проходить через них. Поэтому в различных случаях будет выбираться разный маршрут. Вообще, логика построения такой модели очевидна: надо избегать колец — это одно из основных правил, чтобы не возникали вопросы, аналогичные вашему.

                                            В приведенном примере, где явно не уточняются детали, регион(человек.возраст>20) будет выбираться по кратчайшему пути, т.е. через прописку. Однако, в запрос можно вставить специальные инструкции (как описано в статье и примерно похоже на то, как описано в комментарии ниже), которые укажут функционалу делать выборку через другие связи.
                                              +1
                                              — Ты зачем притащил десять булок хлеба!?
                                              — Потому, что яйца были.
                                              — !??
                                              — Сама же просила: «сходи в магазин, купи хлеба, если будут яйца, возьми десяток».

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

                                              Связный граф без колец (циклов) называется деревом. Эта модель подходит лишь для каких-то вырожденных случаев. Понятийные связи в реальных моделях образуют сети.

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

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

                                          Самое читаемое