关系数据库中可重新排序的父/子层次结构

Question

我正在为我的Rails网站的设计问题而苦苦挣扎。我正在为建筑公司开发一个装修项目的评估工具。

默认情况下，它以这种方式订购项目：

• 房间(除厨房外)
  • 部分(如:绘画)
    • 物品(例如:油漆天花板)

但有时公司更喜欢这样订购商品。

• 区段
  • 房间
    • 项目

在我们的数据库中，这些项与包含其parent_id的子表位于同一个表中。

我给出了在第一和第二显示模式之间快速切换的选项，但是我的方式对我来说并不是很干净。它总是存储在第一个例子中，我有一堆"ifs“来改变它的显示方式。

我找不到更好的方法，也找不到任何关于这个问题的讨论(也许我不知道该去哪里)。

对这种情况有什么最佳做法吗？

Answer 1

而不是实体，让我们看一下这里的关系：

• 一件物品正好是一个房间；一个房间有许多物品
• 一个项目正好代表一个部门；一个部门有许多项
• 一个房间有许多部分；一个部分适用于许多房间(即使在最初的层次结构中，您的示例部分是“绘画”，而不是“绘画厨房”)

所以我们有两种一对多的关系，一种多对多的关系。层次结构是一对多的结构，因此不能正确地模拟房间和部分之间的关系。

相反，您可以显式地建模这些关系：

• 每个项目都有一个房间ID和一个部门ID
• 若要列出某个房间的所有部分，请查看带有该会议室ID的不同区段ID集的项目
• 若要列出某一节的所有房间，请查看带有该节ID的房间ID的不同集合的项目

如果需要针对“房间”和“科”的组合存储信息，则需要创建一个新的实体来表示该组合：

• 每个项目都有一个RoomSection ID
• 每个RoomSection都有一个房间ID和一个区段ID的独特组合
• 若要列出某个房间的所有区段，请在RoomSections中查找带有该房间ID的所有区段ID
• 若要列出区段的所有空间，请在RoomSections中查找带有该节ID的所有房间ID

或者，您可以采取另一种方式，将它变成一个通用的"facet“系统，其中"Room”和“节”作为运行时定义的属性，可以根据需要进行扩展或替换。这种灵活性带来了许多复杂性--例如，您需要重新实现约束之类的东西--所以，除非您确信它会带来价值，否则不要选择这个选项。