GraphDB单个顶点是否支持存储多组数组类型属性
GraphDB顶点属性合并问题解答
核心结论
完全可以将两类电话的属性整合到同一个顶点中,符合TinkerPop规范的GraphDB原生支持单顶点存储多组同结构属性,你可以根据业务场景选择以下两种整合方案:
方案1:按电话类型加属性前缀存储
为不同类型电话的属性增加类型标识前缀,直接存储在同一个顶点的properties下,适合电话类型固定的场景,整合后顶点示例:
{ "id": "CU10611973PHONE", "label": "Phone", "type": "vertex", "properties": { "Home_PhonePreference": [ { "id": "c63cf5c9-329b-456e-b94e-0c500587780f", "value": "Primary" } ], "Home_PhoneType": [ { "id": "11f241d8-8e84-479b-b6a4-aeab7e039665", "value": "Home" } ], "Home_PhoneNumber": [ { "id": "5795e2ec-6d8c-424c-b42d-f01b587caeca", "value": "22222222222" } ], "Cell_PhonePreference": [ { "id": "488c54b2-f256-4053-adc5-c07ec2e1a629", "value": "Primary" } ], "Cell_PhoneType": [ { "id": "2f5263e7-f42b-487f-a185-338682a68fdd", "value": "Cell" } ], "Cell_PhoneNumber": [ { "id": "a967516d-986c-4eac-929a-b86824677922", "value": "123456789" } ], "pk": [ { "id": "CU10611973PHONE|pk", "value": "pk" } ] } }
方案优缺点
- 优点:查询时可直接按属性名取值,无需额外解析,查询性能更高
- 缺点:后续如果要新增办公电话、亲友电话等新类型,需要新增对应属性字段,灵活性较差
方案2:单属性存电话列表
将所有电话信息封装为一个PhoneList多值属性,每个元素对应一组电话属性,适合电话类型可能动态扩展的场景,整合后顶点示例:
{ "id": "CU10611973PHONE", "label": "Phone", "type": "vertex", "properties": { "PhoneList": [ { "id": "c63cf5c9-329b-456e-b94e-0c500587780f", "value": { "PhonePreference": "Primary", "PhoneType": "Home", "PhoneNumber": "22222222222" } }, { "id": "488c54b2-f256-4053-adc5-c07ec2e1a629", "value": { "PhonePreference": "Primary", "PhoneType": "Cell", "PhoneNumber": "123456789" } } ], "pk": [ { "id": "CU10611973PHONE|pk", "value": "pk" } ] } }
方案优缺点
- 优点:无需修改属性结构即可扩展任意类型的电话,批量查询所有电话的效率更高
- 缺点:查询指定类型的电话时需要遍历列表过滤,性能比方案1低
注意事项
如果原两个独立的电话顶点已经关联了其他顶点(比如关联了对应的用户顶点),整合时需要把原来的边都迁移到新的合并顶点上,避免关联关系丢失。
内容的提问来源于stack exchange,提问作者Sneha Nair
相关产品推荐
相关产品推荐

