【发布时间】:2021-07-28 04:49:58
【问题描述】:
我们正在尝试在 Graphdb 中实现面向客户的详细信息,通过单个查询,我们可以获取客户的详细信息,例如他的地址、电话、电子邮件等。我们使用有地址构建它,有电子邮件边缘..
g.addV('member').property('id','CU10611972').property('CustomerId', 'CU10611972').property('TIN', 'xxxx').property('EntityType', 'Person').property('pk', 'pk')
g.addV('email').property('id','CU10611972E').property('pk', 'pk')
g.addV('primary').property('id','CU10611972EP').property('EmailPreference','Primary').property('EmailType', 'Home').property('EmailAddress', 'SNEHA@GMAIL.COM').property('pk', 'pk')
g.V('CU10611972').addE('has Email').to(g.V('CU10611972E'))
g.V('CU10611972E').addE('has Primary Email').to(g.V('CU10611972EP')
这就是我们与客户建立电子邮件关系的方式。同样,我们与地址和电话建立关系。所以现在我们正在使用这个命令来获取与该客户相关的 json 用于电子邮件,
g.V('CU10611972').out('has Email').out('has Primary Email')
对于完整的客户详细信息,我们为每个顶点、电话、电子邮件和地址使用联合......
您能否建议是否有一种有效的方法来查询此详细信息?
【问题讨论】:
-
您决定使用图形对此进行建模是否有原因?它似乎非常适合传统 SQL 建模为具有属性的 Customer 对象。
-
@NoahStahl :是的,基本上我们已经填写了使用 graphdb 的要求,以获得客户的 365 视图。你能帮忙解决一下这种情况吗?
-
对我来说,这似乎是图形建模的错误应用,使存储您显示的数据过于复杂。无论哪种方式,仍然不清楚您的问题是什么?
-
编辑了问题以消除不确定性。只需要一种有效的查询方式,例如我们将来可能有备用电子邮件 id。所以任何人都应该能够轻松查询与客户对应的主要和备用电子邮件 id
标签: azure-cosmosdb gremlin tinkerpop azure-cosmosdb-gremlinapi