我正在开发一个社交媒体类型的网站。我已经开始初步设计并遇到了潜在的问题。该站点围绕组件，子组件和子子组件展开。它具有层次结构。我最初创建了一个组件表，一个子组件表和一个子子组件表。这些表由ID链接。对于大多数事情，我认为这样可以正常工作。但...
我希望用户能够“喜欢”或“关注”某些组件，子组件和子组件。我以为我必须创建一个“喜欢”的表或“交互”表。我没有单一的ID链接。如果用户想要子子组件，则必须列出component_id，sub-component_id和sub-sub-component_id。这似乎是一种痛苦。
那么为什么不拥有1个元素表或只有组件。子组件1和子组件2是组件1的子组件。 sub-sub-component1是子组件2等的子项。
在执行此操作时，我可以创建唯一的component_id，无论组件是子组件还是子子组件，我可以在我喜欢的表中应用这些id。
这看起来是一个更有效的过程吗？我用parent_ids等创建了单个表，现在遇到了查询该表以生成数据的问题。如何显示组件，组件的子组件（作为子组件）以及子组件的子组件（作为子组件）？
我希望这可以让你了解我在寻找什么。如果您需要更多信息，请与我们联系。
答案 0 :(得分：0)
取决于几个方面，每个级别的单独表格还是单个表格更好：
已知，固定且相当小的最大级别数是多少？
彼此之间的等级有多相似？
如果行为可能会有所不同，那么该变化只是某个级别的函数，还是会因其他内容而异？ （组件可以有不同的风格，无论级别如何？）
组件表上需要一个parent_id字段，以便您找到给定事物的所有子项。您可能也想要一个关于此的索引 - 我假设您更频繁地阅读组件的结构而不是它的变化，因此索引的成本超过了它的好处。 / p>
向MySQL表添加索引的示例是in this other SO question。
要考虑的另一件事是在每个节点上放置一个级别计数器。即组件是1级，子组件是2级等。这会使一些工作更容易，例如，如果你想用不同颜色或类似的东西呈现级别。但如果你只是想要一个无差别的事物树，那可能不值得这么麻烦。
关于SO的其他问题涉及MySQL中queries on hierarchical data的细节（有多种方法可以做到这一点，表结构中有相应的小差异）。不同的数据库供应商为这种查询提供了不同的支持，这使得它或多或少变得容易。例如，Oracle有一个非常好的方法hierarchies。
如果你选择单个表，那么不同表和用户之间的链接就是一个表。喜欢是Polymorphic Association的一个例子。 （这是一个SO问题的链接，反过来又链接到另一个 - 两者都很有用。）