Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 58
Интересно, действительно ли для всех SQL-конструкций описан мета-язык запросов? Есть ли GROUP, LIMIT, INNER JOIN?
Можно вопрос: а в виде чего у вас реализован такой объектный сервис? В виде компонента/отдельной службы/чего-то еще? Включает ли он в себя ORM, или функционал маппинга отделен от сервера объектов?
Я бы назвал эту реализацию службой, слушающей определенный порт. ORM имеется и включен в сервер объектов. Задача ORM в данном случае по максимуму избавить веб-разработчика от мыслей о базе данных, зачастую человек вообще не знает, на какой СУБД работает проект. Лишь в особых случаях это приходится вспоминать.
Забавно :) Т.е. у вас своего рода объектная БД с remote-интерфейсом. А там поддерживается весь CRUD, или это только read-only? Если CRUD, то мне интересно решение вопроса с транзакциями через удаленный интерфейс.
Эх, облажался немного, произошло недопонимание.
Да, есть объектная БД, у нее есть внешний интерфейс для работы вспомогательных служб, они действительно через этот интерфейс могут производить CRUD, но это не касается основных приложений, который работают с репозиторием. Они-то как раз работают по вполне обычным интерфейсам языковым, поэтому проблем с транзакциями там нет, как теперь можно понять.
Да, есть объектная БД, у нее есть внешний интерфейс для работы вспомогательных служб, они действительно через этот интерфейс могут производить CRUD, но это не касается основных приложений, который работают с репозиторием. Они-то как раз работают по вполне обычным интерфейсам языковым, поэтому проблем с транзакциями там нет, как теперь можно понять.
Можно вопрос: как добавление службы повлияло на производительность системы в целом? Если большая нагрузка, SQL-запросы как-то еще можна оптимизировать, а так у нас получается черный ящик.
И у вас предусмотрена альтернатива всех возможных запросов, которые можна выполнить с помощью SQL?
Но идея очень интересная.
И у вас предусмотрена альтернатива всех возможных запросов, которые можна выполнить с помощью SQL?
Но идея очень интересная.
Схема существует уже много лет, на ней работали проекты совершенно разной нагруженности. Сложности бывают, но ведь мы обсудили лишь часть общей системы. Есть другие части, которые в том числе нацелены на разгрузку мощностей сервера.
Основная концепция — что простые вещи можно делать простыми средствами. Если становится понятно, что абстракция мешает, то всегда можно реализовать функционал альтернативным способом (благо, MVC придерживаемся). Т.е. к объектному серверу можно обратиться не только через API, но и иными способами, при этом часть алгоритмов, заложенных в объектный сервер просто не буду использоваться. Кроме того, в самом объектном сервере заложены механизмы типа представлений, который иногда тоже позволяют делать хитрые вещи.
Конкретно вмешаться в запрос при обращении через описанные механизмы нельзя. Можно лишь понять, что данная выборка существенно мешает системе, переписав ее на другую, более простую, добавить индексы на нужные атрибуты (делается так же довольно абстрактно от БД).
Т.е. «черный ящик» для разработчика существует до тех пор, пока не возникают проблемы и ему не надо с ними разбираться. При этом средства для изучения проблем имеются.
Основная концепция — что простые вещи можно делать простыми средствами. Если становится понятно, что абстракция мешает, то всегда можно реализовать функционал альтернативным способом (благо, MVC придерживаемся). Т.е. к объектному серверу можно обратиться не только через API, но и иными способами, при этом часть алгоритмов, заложенных в объектный сервер просто не буду использоваться. Кроме того, в самом объектном сервере заложены механизмы типа представлений, который иногда тоже позволяют делать хитрые вещи.
Конкретно вмешаться в запрос при обращении через описанные механизмы нельзя. Можно лишь понять, что данная выборка существенно мешает системе, переписав ее на другую, более простую, добавить индексы на нужные атрибуты (делается так же довольно абстрактно от БД).
Т.е. «черный ящик» для разработчика существует до тех пор, пока не возникают проблемы и ему не надо с ними разбираться. При этом средства для изучения проблем имеются.
Насколько я понял, речь идет о каком-то дополнительном уровне абстракции, позволяющем смоделировать модель предметной области, независимую как от «клиентов» (программ и интерфейсов) ее использующих, так и от конкретных способов хранения данных (будь то файлы, БД, веб-сервисы и так далее)?
В достаточно мере верно сформулировано. Хотя добавить полной независимости от способа хранения не получится, точнее это можно реализовать, но существенной ценой.
Это само собой. В таком случае то, о чем идет речь — Моделирование Домена и использование практик Domain Driven Design.
По поводу независимости от способа хранения данных — зависимыми в модели домена остаются только репозитории (DDD Repositories -), которые можно заменить на другие для другого типа источников данных.
Это хорошо, что все это используется. Считаю это самым грамотным подходом к архитектуре (не вдаваясь в нюансы). Более того, если использовать подходы, основанные на тестировании (TDD), то можно независимо от всего и вся протестировать корректную работу любых бизнес-правил отдельно от приложений, использующих данную модель.
А вот конкретная реализация — в виде ли отдельного app-сервера или еще каким-то образом — отдельная тема, не относящаяся к DDD напрямую.
И забавно, что само определение Модели Домена ни разу не проскользнуло в топике :)
По поводу независимости от способа хранения данных — зависимыми в модели домена остаются только репозитории (DDD Repositories -), которые можно заменить на другие для другого типа источников данных.
Это хорошо, что все это используется. Считаю это самым грамотным подходом к архитектуре (не вдаваясь в нюансы). Более того, если использовать подходы, основанные на тестировании (TDD), то можно независимо от всего и вся протестировать корректную работу любых бизнес-правил отдельно от приложений, использующих данную модель.
А вот конкретная реализация — в виде ли отдельного app-сервера или еще каким-то образом — отдельная тема, не относящаяся к DDD напрямую.
И забавно, что само определение Модели Домена ни разу не проскользнуло в топике :)
Наверное, кому-то бы наличие аббревиатур и терминов облегчило понимание смысла, но кому-то нет. В начале статьи я упомянул о том, что материал для всех кругов разработчиков.
Да, есть есть несколько вариантов реализовать предметную область. Вероятно, существующую у нас систему можно охарактеризовать как Domain Model.
К тому же зачастую (моё мнение) сложно подогнать какую-то систему под одно описание, потому что в ней чего-то недостаёт, а что-то наоборот присутствует, чего нет в упоминаемом паттерно, методике. Поэтому я описал все просто и понятно словами.
Да, есть есть несколько вариантов реализовать предметную область. Вероятно, существующую у нас систему можно охарактеризовать как Domain Model.
К тому же зачастую (моё мнение) сложно подогнать какую-то систему под одно описание, потому что в ней чего-то недостаёт, а что-то наоборот присутствует, чего нет в упоминаемом паттерно, методике. Поэтому я описал все просто и понятно словами.
Да, я вот тоже все это с интересом прочитал и сразу про доменное моделирование подумал.
почему-то мне кажется, что это какой-то overkill для подобной задачи (а это ведь просто подсчёт статистики у вас в примерах, т.е. далеко не самая важная часть работы с данными в типичном веб-приложении), возможно, с другими примерами смотрелось бы интереснее.
Возможно. На что фантазии хватило. Ведь фишка в том, что для подсчета такой статистики, как вы это называли, обычному создателю проекта надо написать всего лишь одну несложную строчку. В ином случае кто-то мог бы написать один SQL-запрос. Я просто привел пример архитектуры в статейке, которая применима для довольно широкого круга задач.
Идея очень интересная, но зачем remote-сервер. Хотелось бы узнать, почему вы не сделали это средствами самого языка?
Я правильно понял, что единственный смысл — спрятать связи между таблицами? Это все что делает объектный сервер?
Спрятать связь? Да, можно спрятать физическую связь, можно создать виртуальную. При этом сервер обладает возможностью анализировать эти связи и выдавать необходимые результаты на сложные запросы без явного указания, как именно эти связи строить. Основная фишка не в объектности, абстрактности, а именно в автоматической связываемости объектов. И это касается не только при запросах на чтение, но и на запись, например, постинг форм, в которых множество объектов содержит свои данные.
очень напомнило реализацию ORM в django.
Не, не, думаю, ORM — это способ доступа к данным и из представление в особом виде (в объектах языка) и это всего лишь инструмент. А выделение предметной области — это немного другое, я так понял, именно о последнем идет речь.
ну инструмент, на мой взгляд, как раз для облегчения работы с предметной областью.
1. определяем сущности предметной области.
2. описание этих сущностей на ЯП
3. работа с ними.
4.…
5. PROFIT.
Единственное отличие на мой взгляд, это то, что автор предлагает работать без привязки к хранилищу данных, что в принципе достаточно странно, поскольку можно сделать прослойку используя кеш и тем самым решить проблему с нагрузкой на хранилище.
1. определяем сущности предметной области.
2. описание этих сущностей на ЯП
3. работа с ними.
4.…
5. PROFIT.
Единственное отличие на мой взгляд, это то, что автор предлагает работать без привязки к хранилищу данных, что в принципе достаточно странно, поскольку можно сделать прослойку используя кеш и тем самым решить проблему с нагрузкой на хранилище.
«ну инструмент, на мой взгляд, как раз для облегчения работы с предметной областью.»
Это да, но во-первых, инструмент не единственный, а во-вторых не только для работы с предметной областью. Так что делаем вывод, что это разные вещи.
И отличий тут можно не искать — это концептуально разные вещи. ORM как раз работает на уровне DAL (доступ к данным) и отвечает за сохраниние и выборку объектов, которые _после этого_ будут использоваться в модели предметной области.
При этом модель предметной области может в другой своей части использовать вообще другой источник данных, даже не СУБД, а, к примеру, веб-сервис, и там ORM вообще не будет (в то время как модель предметной области свои данные получать будет).
Это да, но во-первых, инструмент не единственный, а во-вторых не только для работы с предметной областью. Так что делаем вывод, что это разные вещи.
И отличий тут можно не искать — это концептуально разные вещи. ORM как раз работает на уровне DAL (доступ к данным) и отвечает за сохраниние и выборку объектов, которые _после этого_ будут использоваться в модели предметной области.
При этом модель предметной области может в другой своей части использовать вообще другой источник данных, даже не СУБД, а, к примеру, веб-сервис, и там ORM вообще не будет (в то время как модель предметной области свои данные получать будет).
я и не говорил, что должно обязательно быть СУБД, задача ORM как раз в том, что бы представить данные в форме сущностей и методы для работы с ними.
Не вижу принципиальной разницы в хранилище, особенно если вспомнить о DTO.
Впрочем мы немного отвлеклись, я не совсем правильно выразил свою мысль которую возникла прочитав этот пост.
Я имел ввиду, что то что описывает автор, время от времени приводя реализацию на псевдо-коде, очень сильно мне напомнило, работу с сущностями в django используя родные для неё возможности ORM
Не вижу принципиальной разницы в хранилище, особенно если вспомнить о DTO.
Впрочем мы немного отвлеклись, я не совсем правильно выразил свою мысль которую возникла прочитав этот пост.
Я имел ввиду, что то что описывает автор, время от времени приводя реализацию на псевдо-коде, очень сильно мне напомнило, работу с сущностями в django используя родные для неё возможности ORM
Если не сложно, можете привести, как в упоминаемом фреймворке можно получить (синтаксис) данные, как в одном из моих примеров в статье?
посмотрите здесь как реализаванны связи many to many
парсер съел коммент.
www.djangoproject.com/documentation/models/many_to_many/
www.djangoproject.com/documentation/models/many_to_many/
для более быстрого примера сделаю копи-паст прямо оттуда:
Определение моделей:
Создание:
Добавление
Выборка
Выборка с фильтром
Определение моделей:
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)
«В ближайшее время Mozart скорее всего будет опубликован с открытыми исходными кодами под одной из свободных лицензий.»
Не забудьте об этом погромче сообщить, пойду еще раз перечетаю Ваш пост.
Не забудьте об этом погромче сообщить, пойду еще раз перечетаю Ваш пост.
Подход интересен, насколько я понял, вы выделили ORM-интерфейс к базе данных (и к другим хранилищам) в отдельный объектный сервер (под ORM понимаем вообще любые объекты с определенными связями и операции над ними). Но при этом возникает множество вопросов:
1. На чем основывалось решение реализовать систему в виде демона, а не как обычный модуль? Практически все крупные компании пошли по второму пути: .Net Entities, Hibernate и т.д.
2. Насколько увеличивается латентность запроса? Если до этого приходилось иметь только пул подключений к базе данных, то теперь добавился еще один: к объектному серверу.
3. Какой оверхед вносит объектный сервер? Насколько быстро он может построить
необходимые запросы для базы данных?
4. API объектного сервера проще, чем SQL (иначе, в нем нет смысла). Большинство операций над данными сильно упрощается, но что делать, когда потребуются все возможности SQL? Насколько сложно реализуются именно нетипичные запросы (вложенные, рекурсивные и т.д.)? Возможны ли они вообще?
5. Как происходит доступ к вычислениям (Avg, Sum и т.д.)? Допустим, надо получить всех операторов из определенного региона и количество их пользователей.
6. Допустим, необходимо получить список людей вместе с телефонами и пропиской. Возможно ли получение объекта с его «детями» за один запрос, указав «выбрать связанные» (select related)? Или придется делать множество маленьких запросов?
Вообще, очень интересно было бы посмотреть именно на реализацию. Буду надеяться, исходные коды и правда будут открыты.
1. На чем основывалось решение реализовать систему в виде демона, а не как обычный модуль? Практически все крупные компании пошли по второму пути: .Net Entities, Hibernate и т.д.
2. Насколько увеличивается латентность запроса? Если до этого приходилось иметь только пул подключений к базе данных, то теперь добавился еще один: к объектному серверу.
3. Какой оверхед вносит объектный сервер? Насколько быстро он может построить
необходимые запросы для базы данных?
4. API объектного сервера проще, чем SQL (иначе, в нем нет смысла). Большинство операций над данными сильно упрощается, но что делать, когда потребуются все возможности SQL? Насколько сложно реализуются именно нетипичные запросы (вложенные, рекурсивные и т.д.)? Возможны ли они вообще?
5. Как происходит доступ к вычислениям (Avg, Sum и т.д.)? Допустим, надо получить всех операторов из определенного региона и количество их пользователей.
6. Допустим, необходимо получить список людей вместе с телефонами и пропиской. Возможно ли получение объекта с его «детями» за один запрос, указав «выбрать связанные» (select related)? Или придется делать множество маленьких запросов?
Вообще, очень интересно было бы посмотреть именно на реализацию. Буду надеяться, исходные коды и правда будут открыты.
1. Переабстрагировался в описании и запутал читателей. Назовем это не сервером, а службой, поэтому никакого процесса-демона нет. Цитата свыше: «Да, есть объектная БД, у нее есть внешний интерфейс для работы вспомогательных служб, они действительно через этот интерфейс могут производить CRUD, но это не касается основных приложений, который работают с репозиторием. Они-то как раз работают по вполне обычным интерфейсам языковым, поэтому проблем с транзакциями там нет, как теперь можно понять.»
3. Хотя от понятия сервер мы вроде как избавились, однако этот вопрос актуален в любом случае. Вопрос неоднозначный, поскольку существенно зависит от сложности запроса и объема данных, с которыми оперирует механизм. На практике у нас с этим нет никаких проблем. Обычно совсем другие этапы обработки вносят задержки, нежели построение связей, запросов. Безусловно, не обошлось без кэширования.
4. API системы, которая работает с репозиторием, вполне простой и затачивался всегда под то, чтобы с ним мог работать HTML-верстальщик без особых знаний программирования. Есть иные механизмы работы с репозиторием, в которых можно писать практически любые иные запросы и даже влиять на то, как работают существующий API.
5. Есть несколько способов оперировать такой логикой: на уровне репозитория через «калькулируемые» объекты, атрибуты, связи, на уровне контроллера через API, комбинирование этих методов. Есть отличные идеи, которые именно для таких случаев мы бы хотели реализовать, но нет пока возможности.
6. Вы идентифицируете человека и говорите, что с ним хотите взять Телефон и Прописка. Система сама построит связь и вытащить нужные данные в удобочитаемой форме. Возможность сказать «select related» нет, ибо связанных сущностей может быть очень много, сколько уровней взять, все деревно или один слой?.. Если, конечно, хранилище построено логично и такая связь прослеживается.
3. Хотя от понятия сервер мы вроде как избавились, однако этот вопрос актуален в любом случае. Вопрос неоднозначный, поскольку существенно зависит от сложности запроса и объема данных, с которыми оперирует механизм. На практике у нас с этим нет никаких проблем. Обычно совсем другие этапы обработки вносят задержки, нежели построение связей, запросов. Безусловно, не обошлось без кэширования.
4. API системы, которая работает с репозиторием, вполне простой и затачивался всегда под то, чтобы с ним мог работать HTML-верстальщик без особых знаний программирования. Есть иные механизмы работы с репозиторием, в которых можно писать практически любые иные запросы и даже влиять на то, как работают существующий API.
5. Есть несколько способов оперировать такой логикой: на уровне репозитория через «калькулируемые» объекты, атрибуты, связи, на уровне контроллера через API, комбинирование этих методов. Есть отличные идеи, которые именно для таких случаев мы бы хотели реализовать, но нет пока возможности.
6. Вы идентифицируете человека и говорите, что с ним хотите взять Телефон и Прописка. Система сама построит связь и вытащить нужные данные в удобочитаемой форме. Возможность сказать «select related» нет, ибо связанных сущностей может быть очень много, сколько уровней взять, все деревно или один слой?.. Если, конечно, хранилище построено логично и такая связь прослеживается.
Хороший топик.
Вопрос автору: а не пробовали использовать технологию для других приложений (не вебом единым живем)?
У меня самого стремительно бежит мысль, чтобы явно выделить отношения предметной области и абстракции из языка программирования, оставив ему только низкоуровневую работу… И показанная здесь идея очень точно соответствует этой задумке. Вот и соображаю, как бы сэкономить на объеме кодинга для диплома )
Вопрос автору: а не пробовали использовать технологию для других приложений (не вебом единым живем)?
У меня самого стремительно бежит мысль, чтобы явно выделить отношения предметной области и абстракции из языка программирования, оставив ему только низкоуровневую работу… И показанная здесь идея очень точно соответствует этой задумке. Вот и соображаю, как бы сэкономить на объеме кодинга для диплома )
Все описанное реализовано на Java. Задумка была такая, чтобы сделать систему хранения, которая как самостоятельная единица. В нашей практике с ней работает часть сервлета, отвечающая за обработку веб-запросов (ну или сам сервелат, если более правильно). Ничто не мешает сделать любое другое приложение.
Что касается диплома, то вряд ли кому-то нужна полностью рабочая программа. Думаю, что достаточно иметь красивую концепцию и какую часть ее реализации. Там уже станет понятно, стоит ли ее развивать дальше, или это велосипед, или получается что-то сложное…
Что касается диплома, то вряд ли кому-то нужна полностью рабочая программа. Думаю, что достаточно иметь красивую концепцию и какую часть ее реализации. Там уже станет понятно, стоит ли ее развивать дальше, или это велосипед, или получается что-то сложное…
Дмитрий, какие цели преследует ADV, публикуя Mozart в открытых исходных кодах под одной из свободных лицензий?
Нам кажется, что наш продукт будет интересен сообществу профессиональных разработчиков. Мы много сил потратили на разработку Mozart, и у нас большие планы по развитию системы. Формат открытых исходных кодов кажется нам наиболее правильным с точки зрения популяризации продукта и построения эффективной системы обратной связи с пользователями.
Такой способ популяризации в первую очередь направлен на непосредственных разработчиков. Вы планируете выстроить партнерскую сеть или сообщество пользователей?
И еще: чем вы руководствуетесь при выборе между Mozart'ом и 1С-Битриксом для каждого конкретного проекта?
И еще: чем вы руководствуетесь при выборе между Mozart'ом и 1С-Битриксом для каждого конкретного проекта?
Второй вопрос не по адресу, я лично не принимаю решения.
Планы в какой-то степени большие, но далеко загадывать бы не хотелось, потому что надо будет действовать по обстоятельствам. Я заинтересован в сообществе, которое будет как принимать участие в разработке системы, так и в ее использовании для разработки своих веб-проектов.
Планы в какой-то степени большие, но далеко загадывать бы не хотелось, потому что надо будет действовать по обстоятельствам. Я заинтересован в сообществе, которое будет как принимать участие в разработке системы, так и в ее использовании для разработки своих веб-проектов.
На мой взгляд это правильный подход. Я как-то дошел до аналогичной мысли и пошерстил немного интернет в поисках готовых реализаций сего дела.
Эта штука боле-менее общепринято называется EAV/CR — «entity-attribute-value with classes and relationships» И не все считают ее хорошей идеей. Иногда EAV приводится в качестве антипаттерна из-за возможных сбоев.
Самое раннее описание что я видел — www.interface.ru/fset.asp?Url=/misc/hran_01.htm за 2002 год.
Сам хочу обзавестись подобным функционалом для своих проектов. Посуму вопрос — когда можно ждать Mozart? Или может быть кто из хабрапесателей поможет мне в написании своего велосипеда на эту тему?
Эта штука боле-менее общепринято называется EAV/CR — «entity-attribute-value with classes and relationships» И не все считают ее хорошей идеей. Иногда EAV приводится в качестве антипаттерна из-за возможных сбоев.
Самое раннее описание что я видел — www.interface.ru/fset.asp?Url=/misc/hran_01.htm за 2002 год.
Сам хочу обзавестись подобным функционалом для своих проектов. Посуму вопрос — когда можно ждать Mozart? Или может быть кто из хабрапесателей поможет мне в написании своего велосипеда на эту тему?
Нет. Мы не практикуем такого. Однажды была идея сделать нечто подобное, даже есть практические работающие варианты.
Ребят это круть, что вы используете hibernate в своем продукте, но когда я вижу «Документ:: Блок слоя» я понимаю кто единственный пользователь этого продукта. P.S. есть проекты в которых разработчику не до связей которые нагенерил фреймворк и не до названий таблиц…
Написал личное сообщение по теме…
Целью статьи являлось показать, что при разработке какой-либо системы управления зачастую лучше задуматься не только о том, какие таблицы будут в БД и как они связаны, а еще и о том, какие инструменты для работы с ними предлагаются.
при большом объеме взаимосвязанных объектов, держать в голове все их взаимосвязи так же тяжело как и связи в реляционной БД, не говоря уж о том чтобы задумываться какие там таблицы и связки насоздает ORM, мониторить их нужно, но вот выполнять работу фреймворка, зачем?
при большом объеме взаимосвязанных объектов, держать в голове все их взаимосвязи так же тяжело как и связи в реляционной БД, не говоря уж о том чтобы задумываться какие там таблицы и связки насоздает ORM, мониторить их нужно, но вот выполнять работу фреймворка, зачем?
Еще такое наблюдение: данная система очень напоминает семантическую сеть или, что потенциально ближе, ER-диаграмму (только очень прошу, не надо ее путать с реляционной диаграммой — это очень распространенная ошибка, в том числе в современных средствах проектирования). А зная историю и корни ER-диаграмм, можно сказать, что данная идея является более фундаментальной, чем те же РБД или даже ООП. Отсюда 2 вопроса:
1. Проводили ли вы фундаментальные исследования в этой области? Если да, то можете ли поделиться, если нет, то заинтересованы ли вы в них и планируете ли проводить?
2. Заинтересует ли вас низкоуровневая реализация такой системы? (То есть когда работу семантической сети выполняет отдельное приложение — это обосновывается фундаментальным характером самой идеи, из-за которого реализация в объектах может содержать много лишнего)
1. Проводили ли вы фундаментальные исследования в этой области? Если да, то можете ли поделиться, если нет, то заинтересованы ли вы в них и планируете ли проводить?
2. Заинтересует ли вас низкоуровневая реализация такой системы? (То есть когда работу семантической сети выполняет отдельное приложение — это обосновывается фундаментальным характером самой идеи, из-за которого реализация в объектах может содержать много лишнего)
Зачастую, перед реализацией проекта проектируется сама модель хранения: прямо на бумаге рисуется некое упрощение ER-диаграммы. Зачастую мы это делаем уже на более сложных существующих проектах, чтобы провести ревизию.
Но, боюсь, я не очень озадачивался данными теоретическими вопросами. Мы ведь занимаемся не сколько научной теоретикой, сколько средствами для практического применения. Могу лишь предположить, что наша идея, ее реализация все-таки более ближе к реляционной ее части, потому как в основу хранилища обычно у нас положена реляционная СУБД.
Но, боюсь, я не очень озадачивался данными теоретическими вопросами. Мы ведь занимаемся не сколько научной теоретикой, сколько средствами для практического применения. Могу лишь предположить, что наша идея, ее реализация все-таки более ближе к реляционной ее части, потому как в основу хранилища обычно у нас положена реляционная СУБД.
Зачем же так жёстко =)
1. Я хотел описать некую архитектуру, с помощью которой можно проектировать хранилища данных, и которая позволяет упрощать работу с ними.
2. Я не пытался описать работу какой-то системы с конкретными примерами, как в ней это устроено, как выглядит синтаксис запросов. Да, система есть и она работает. Возможно, в одной из будущих статей я затрону ее API.
3. Почему я должен приводить какие-то отличия? Я сказал, что система, используемая в качестве первоисточника статьи, называется Mozart. И она существует уже более 10 лет, как закрытая система разработки внутри компании. Вы можете привести примеры подобных систем, существующих более 10 лет назад? Да и вообще я не пытался сказать, какая моя система уникальная. Потому что я не знаю всех уже существующих систем, их истории. Я просто констатировал, что такая система есть.
1. Я хотел описать некую архитектуру, с помощью которой можно проектировать хранилища данных, и которая позволяет упрощать работу с ними.
2. Я не пытался описать работу какой-то системы с конкретными примерами, как в ней это устроено, как выглядит синтаксис запросов. Да, система есть и она работает. Возможно, в одной из будущих статей я затрону ее API.
3. Почему я должен приводить какие-то отличия? Я сказал, что система, используемая в качестве первоисточника статьи, называется Mozart. И она существует уже более 10 лет, как закрытая система разработки внутри компании. Вы можете привести примеры подобных систем, существующих более 10 лет назад? Да и вообще я не пытался сказать, какая моя система уникальная. Потому что я не знаю всех уже существующих систем, их истории. Я просто констатировал, что такая система есть.
регион(человек.возраст>20)
и как понять, какие же регионы в итоге выбираются:
1. где человеки имеют подключеные симки к региональным тарифам
2. где прописаны человеки
?
будет выбран самый легкий путь?
ок. допустим, изначально (во время реализации) в графе существовал только первый путь (через тарифы). что происходит с приложением, выполняющим этот запрос, после добавления в БД нового, более «легкого», пути (через прописку, в данном случае)?
так на онтологии похоже. :)
и как понять, какие же регионы в итоге выбираются:
1. где человеки имеют подключеные симки к региональным тарифам
2. где прописаны человеки
Я, конечно, не автор, но судя по логике предикатов, будет выбран регион, связанный с человеком непосредственно. Для симки конструкция выглядела б примерно так: регион(симка.человек.возраст > 20)
так на онтологии похоже. :)они и есть =)
Как описано в статье, выбирается наиболее короткий путь. Так же там написано, что вершины графа могут иметь определенный параметр, запрещающий проходить через них. Поэтому в различных случаях будет выбираться разный маршрут. Вообще, логика построения такой модели очевидна: надо избегать колец — это одно из основных правил, чтобы не возникали вопросы, аналогичные вашему.
В приведенном примере, где явно не уточняются детали, регион(человек.возраст>20) будет выбираться по кратчайшему пути, т.е. через прописку. Однако, в запрос можно вставить специальные инструкции (как описано в статье и примерно похоже на то, как описано в комментарии ниже), которые укажут функционалу делать выборку через другие связи.
В приведенном примере, где явно не уточняются детали, регион(человек.возраст>20) будет выбираться по кратчайшему пути, т.е. через прописку. Однако, в запрос можно вставить специальные инструкции (как описано в статье и примерно похоже на то, как описано в комментарии ниже), которые укажут функционалу делать выборку через другие связи.
— Ты зачем притащил десять булок хлеба!?
— Потому, что яйца были.
— !??
— Сама же просила: «сходи в магазин, купи хлеба, если будут яйца, возьми десяток».
Ваша модель позволяет сократить время разработки, за счет того, что сама может достраивать пути запроса. Однако, у меня создалось впечатление, что в процессе эксплуатации это может приводить к появлению не очевидных багов, поскольку добавление новых связей может изменять пути уже существующих запросов (а следовательно, и семантику их результатов).
Связный граф без колец (циклов) называется деревом. Эта модель подходит лишь для каких-то вырожденных случаев. Понятийные связи в реальных моделях образуют сети.
В общем, для меня многое осталось не ясным. Буду ждать релиза в опенсорц, для того чтобы посмотреть как это работает на практике.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура предметной области в CMF/CMS системах