你在这里所描述的听起来像是你如何考虑超图的建模。如果有重要的，使用你的丈夫和妻子的例子在巴里和西莉亚之前声明，那么你可以考虑建模丈夫和妻子作为他们自己的权利的节点，然后当巴里和西莉亚的数据被输入到数据库中，你会把他们附加到这些节点。你可能会改变建模的方式。但是（许多）示例可以是(Wife)<-[:HAS_REL_TYPE]-(Celia)-[:KNOWS]->(Barry)-[:HAS_REL_TYPE]->(Husband)

免责声明，我是golang typeDB的维护者。
前面的答案是正确的，您的用例需要用隐式逆关系和N元关系来建模超图。据我所知，TypeDB允许您这样做。
https://vaticle.com/typedb
对于您关于避免迁移的具体问题，据我所知，在以下情况下，您不需要迁移任何内容：

• 您的新关系可以表示为规则。例如：如果city in country和city in continent，则city in continent。TypeDB在查询时应用这些规则，这意味着您可以查询亚洲所有城市，并获得q个正确的列表。此外，TypeDB支持类型层次结构，即首都是城市子类型，因此您可以将两者合并起来，即查询欧洲的所有首都，您将得到正确的回答。用规则表达的东西令人印象深刻，而且规则可以自由地添加到模式之后。
• 您的架构更新仅是添加性的，也就是说，您对结婚、离婚以及两者的位置进行建模，并且在稍后的某个时刻，您希望添加蜜月并将其链接到位置。您可以对实体蜜月执行此操作，但必须在架构更改后更新现有数据。同样，规则是您的朋友，这意味着您无需编写关系，而是制定规则。

显然，非附加性更改（即更改实体、删除属性或更改现有关系）需要某种形式的数据修改或迁移。
如果你更喜欢传统的无模式noSQL DB，Arrango可以为你提供超图和开放模式，但不允许子类型和规则，而是必须将所有规则表述为显式关系。
就个人而言，如果性能，特别是规模性能是最高优先级，Arrango是不可能击败的。如果你需要更大的超极端行星规模，那么只有无限图可以做的工作。
相反，如果功能和特别复杂的领域需求是最重要的，而性能只需要是好的，那么没有什么能击败TypeDB。事实上，一半的大型制药公司使用TypeDB来建模药物发现所需的复杂生物数据。TypeDB支持数十亿的行业，而且，据我所知，很少有图形数据库能够像typeDB那样在降低复杂性的同时提高表达能力。