在图形数据库中表示烹饪食谱
我正在尝试了解图形数据库。所以也许有人可以帮助我解释建立这种关系模型的正确方法。这主要是从 Neo4j 的角度来看的,但我认为它适用于大多数图形数据库,
我有一个 Recipe
节点和 Ingredient
节点。 Ingredient
节点与 Recipe
节点具有 ingredient_in
关系。该关系将包含多个属性,特别值得注意的是带有计量单位的金额字段。
我可以想象在图表的其他地方会有一个 UnitOfMeasure
节点,它们与转换比率具有 Converts_to 关系。
我正在努力解决的问题是如何将成分->配方关系表示为具有测量单位。来自 RDMS 的感觉就像我需要在两者之间添加另一个节点,但这对于图形数据库来说感觉是错误的。
I'm trying to wrap my head around graph databases. So maybe someone could help explain to me the right way to model this relationship. This is mostly from the perspective of neo4j, but I assume it would be applicable to most graph databases
I have a Recipe
node and Ingredient
nodes. The Ingredient
nodes have a ingredient_in
relationship to the Recipe
node. The relationship will hold several attributes, of particular note is an amount field with a unit of measure.
I can imagine that elsewhere in the graph there would be a UnitOfMeasure
nodes that would have converts_to relationships with a conversion ratio.
The point I'm struggling with is how do I represent the Ingredient->Recipe relationship as having a UnitOfMeasure. Coming from RDMS this feels like I need a another node in between, but that feels wrong for a graph database.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这取决于两件事:
a)你是否有属性关系或n元关系
b)你如何使用单位和金额 - 可能中间的节点更容易
Imo,使用像这样的“正常”设计
对于Entry来说很好作为节点 - 即使您使用可以处理属性边的图形数据库。顺便说一句,设计与属性 n 元边完全相同 - 唯一的区别是 Entry(现在可能命名为“包含”)将是边而不是节点。
It depends on two things:
a) do you have attributed relations or n-ary relations
b) how do you use the units and amounts - possibly a node in between is easier
Imo, using a "normal" design like this
is fine with Entry being a Node - even if you use a graph database which can handle attributed edges. The design would be quite the same with an attributed n-ary edge btw - the only difference would be that Entry, now possibly named "contains", would be an Edge not a Node.