在图形数据库中表示烹饪食谱

发布于 2024-12-09 13:46:07 字数 436 浏览 0 评论 0原文

我正在尝试了解图形数据库。所以也许有人可以帮助我解释建立这种关系模型的正确方法。这主要是从 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

执手闯天涯 2024-12-16 13:46:07

这取决于两件事:

a)你是否有属性关系或n元关系

b)你如何使用单位和金额 - 可能中间的节点更容易

Imo,使用像这样的“正常”设计

Recipe -- Entry          -- Ingredient
          amount: double
             |
             |
          UniOfMeasure

对于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

Recipe -- Entry          -- Ingredient
          amount: double
             |
             |
          UniOfMeasure

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文