Базы данных графов для моделирования конкретной предметной области

Определенно возможно.

Я работал над этой проблемой с помощью Neo4j, и результатом стал Restagraph. Он предоставляет REST API, который применяет схему при любых обновлениях базы данных, и я упаковал его как образ Docker.

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

TLDR: в целом да, но это зависит от обстоятельств.

Это очень широкий вопрос, поэтому позвольте мне его разбить.

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

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

Большинство графовых баз данных включают что-то вроде типа, аналогично тому, что представляет собой таблица в базах данных SQL. Некоторые позволяют ограничивать отношения только целевыми определенными типами, поэтому вы можете ограничить отношения, например. между узлом, использующим шину CAN и шину I2C, к конкретным типам.

Если база данных не предоставляет эти механизмы, обычно можно ограничить отношения наличием определенных ключей и значений в модели. Чтобы иметь другой пример, чем ваша схема: представьте систему на основе узлов, которая имеет типизированные входы и выходы - выход на основе int может быть подключен только к входу на основе int, выход на основе float только к входу на основе float и т. д. Затем вы можете добавить поля output_type и input_type к узлам и ограничить отношения между значениями.

Как только вы добавите возможность писать (сохраненные процедуры, подобные SQL), вы может писать очень сложные ограничения целостности данных.

Итак, хотя это возможно возможно, вопрос в том, стоит ли это делать.

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

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

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

Объективность/БД — это база данных объектов/графов, использующая схему. Вы вполне можете сделать то, что предлагаете. Он поддерживает сложные определения объектов, включая наследование типов, и имеет полный граф/навигационный язык запросов, аналогичный Cypher. www.objectivity.com