У этого решения есть недостатки, такие как нарушение синхронизации при замедлении процесса или медленная синхронизация (не в реальном времени).

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

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

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

Информация о взаимоотношениях будет широко использоваться во всей системе. Пример некоторых информационных запросов, которые мы хотим выполнить:

Получить всех «ключевых контактов» людей из компаний, которые являются «клиентами» «XYZ Limited»Получить всех других «акционеров» компаний, в которых «Джон» является акционеромПолучить всех «ключевых контактов» людей из организаций, которые являются «клиентами» ABC Limited и являются клиентами «доверяйте нам банк с ограниченной»

Учитывая эту «древовидную» структуру отношений, более ли уместно использовать базу данных графов (например, Neo4j)?

Ответы на вопрос(3)

Ваш ответ на вопрос