使用特殊中心节点建模有向图

发布于 2024-07-29 05:37:43 字数 532 浏览 4 评论 0原文

我正在寻找有关如何对包含一个特殊节点的有向图进行建模的意见。

特殊节点:

  1. 不能有任何边通向它。
  2. 无法删除。

当前设计:

表:节点、边。 边包含两列; from_node_id 和 to_node_id,每个都引用 Nodes 表中的一条记录。

我没有将特殊节点存储为 Nodes 表中的第一条记录,而是决定根本不保留它的记录,而是将其与任何数据库查询分开构建。 在 Edges 表中,from_node_id 列中的 NULL 具有特殊含义,指的是中心节点。

我使用此设计的动机是,我不必担心保护中心节点记录不被删除/修改或在 Edges 表的 to_node_id 列中被引用。 这也会自动阻止边缘往返于同一节点。 我意识到这种设计有一些缺点,例如无法使 from_node_id 和 to_node_id 成为复合主键,可能还有更多。

我目前倾向于使中心节点成为实际记录,并在相关数据库方法中创建对该节点的检查。 进行此设计的最佳方法是什么?

I'm looking for opinions on how to model a directed graph that contains one special node.

Special node:

  1. Cannot have any edges leading to it.
  2. Cannot be removed.

Current design:

Tables: Nodes, Edges. Edges contains two columns; from_node_id and to_node_id, each referencing a record in the Nodes table.

Rather than storing the special node as the first record in the Nodes table, I decided not to keep a record for it at all, constructing it separately from any database queries. In the Edges table, NULL takes on a special meaning in from_node_id column, referring to the center node.

My motivation for using this design was that I wouldn't have to worry about protecting a center node record from deletion/modification or being referenced in the to_node_id column of the Edges table. This would also automatically prevent an edge from going from and to the same node. I realize there are some drawbacks to this design, such as not being able to make from_node_id and to_node_id a composite primary key, and probably many more.

I'm currently leaning towards making the center node an actual record and creating checks for that node in the relevant database methods. What's the best way to go about this design?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

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

发布评论

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

评论(1

你曾走过我的故事 2024-08-05 05:37:43

我看到一些反对在这种情况下使用 NULL 的论点。

  1. 如果节点包含实际数据,则必须对应用程序中的中心节点的数据进行硬编码。
  2. 如果中心节点可以改变的话就会有麻烦。
  3. NULL通常的含义是没有值或者值未知。 因此,另一个接近所提出的设计的人可能会发现它不直观。

换句话说,我更愿意在数据库中为中心节点保留行。

I see some arguments against using NULL in this case.

  1. If nodes contain actual data you would have to hard-code data for the central node in the application.
  2. There will be trouble if the central node can be changed.
  3. The usual meaning of NULL is that there is no value or the value is unknown. Because of this another person who approaches the proposed design could find it unintuitive.

In other words I would prefer to have row in the database for the central node.

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