Table 社交媒体内容的结构
Table structure for social media content
我正在开发一个社交媒体类型的网站。我已经开始初步设计并 运行 解决潜在问题。该站点围绕组件 sub-components 和子 sub-components 展开。它具有层次结构。我最初为组件创建了一个 table，为 sub-components 创建了一个 table，为子 sub-components 创建了一个 table。这些 table 由 id link 编辑。我相信，对于大多数情况，这都可以正常工作。但是...
我希望用户能够 "like" 或 "follow" 某些组件，sub-components 和子 sub-components。我在想我必须创建一个 "like" table 或 "interaction" table。我没有 link 的单一 ID。如果用户想要 sub-sub-component，我必须列出 component_id、sub-component_id 和 sub-sub-component_id。这似乎很痛苦。
那么为什么不使用 1 table 个元素或仅使用组件。 Sub-component1和sub-component2是Component1的children。 sub-sub-component1 是 sub-component2 等的 child
在这样做的过程中，我可以创建唯一的 component_ids，无论组件是 sub-component 还是 sub-sub-component，我都可以根据自己的喜好应用这些 ID table .
这看起来是一个更有效率的过程吗？我已经用 parent_ids 等创建了单个 table，现在 运行 遇到了查询此 table 以生成数据的问题。如何显示组件，组件的 child（如 sub-component）和子组件的 child（如 sub-sub-component）？
我希望这能让您了解我在寻找什么。如果您需要更多信息，请告诉我。
每个级别单独 table 还是单个 table 更好取决于几个因素：
最大级别数是否已知、固定且相当小？
- 否 => 你需要一个 table，否则你会有太多不同的 table，理论上可以构建一个足够深的结构，需要一个 table不存在。
各个级别之间的相似程度如何？
- 如果它们的行为相同，那么你只需要一个table。
如果行为可以变化，那么这种变化是仅随级别变化的函数，还是可以随其他因素变化？ （无论级别如何，组件都可以有不同的风格吗？）
- 如果行为的变化只是因为级别，那是支持每个级别不同 table 的论据（尽管请参阅其他要点）。
- 如果行为的变化实际上是随机的，我会用一个 table 来显示结构，然后再用 1+ 个其他 table 来涵盖行为的差异（即linked 到结构 table).
组件 table 需要一个 parent_id 字段，让您找到给定事物的所有子项。您可能也想要一个关于此的索引 - 我假设您阅读组件结构的频率高于它的变化，因此索引的成本超过了它的好处。
向 MySQL table 添加索引的示例是 in this other SO question.
另一件需要考虑的事情是在每个节点上放置一个级别计数器。 IE。组件是级别 1，子组件是级别 2 等。这将使一些工作更容易，例如，如果你想用不同的颜色或类似的东西来呈现级别。但如果你只是想要一棵无差别的事物树，那可能不值得。
关于 queries on hierarchical data in MySQL (there is more than one way to do it, with corresponding small differences in the table structure). Different database vendors give you different amounts of support for this kind of query, which makes it more or less easy. Oracle, for instance, has a very nice way to do hierarchies 的细节还有其他问题。
如果您确实选择单个 table，则不同 table 之间的 link 和用户的喜好就是 Polymorphic Association 的一个示例。 （这是一个 SO 问题的 link，它又对另一个问题有一个 link - 两者都很有用。）
我正在开发一个社交媒体类型的网站。我已经开始初步设计并 运行 解决潜在问题。该站点围绕组件 sub-components 和子 sub-components 展开。它具有层次结构。我最初为组件创建了一个 table，为 sub-components 创建了一个 table，为子 sub-components 创建了一个 table。这些 table 由 id link 编辑。我相信，对于大多数情况，这都可以正常工作。但是...
我希望用户能够 "like" 或 "follow" 某些组件，sub-components 和子 sub-components。我在想我必须创建一个 "like" table 或 "interaction" table。我没有 link 的单一 ID。如果用户想要 sub-sub-component，我必须列出 component_id、sub-component_id 和 sub-sub-component_id。这似乎很痛苦。
那么为什么不使用 1 table 个元素或仅使用组件。 Sub-component1和sub-component2是Component1的children。 sub-sub-component1 是 sub-component2 等的 child
在这样做的过程中，我可以创建唯一的 component_ids，无论组件是 sub-component 还是 sub-sub-component，我都可以根据自己的喜好应用这些 ID table .
这看起来是一个更有效率的过程吗？我已经用 parent_ids 等创建了单个 table，现在 运行 遇到了查询此 table 以生成数据的问题。如何显示组件，组件的 child（如 sub-component）和子组件的 child（如 sub-sub-component）？
我希望这能让您了解我在寻找什么。如果您需要更多信息，请告诉我。
每个级别单独 table 还是单个 table 更好取决于几个因素：
最大级别数是否已知、固定且相当小？
- 否 => 你需要一个 table，否则你会有太多不同的 table，理论上可以构建一个足够深的结构，需要一个 table不存在。
各个级别之间的相似程度如何？
- 如果它们的行为相同，那么你只需要一个table。
如果行为可以变化，那么这种变化是仅随级别变化的函数，还是可以随其他因素变化？ （无论级别如何，组件都可以有不同的风格吗？）
- 如果行为的变化只是因为级别，那是支持每个级别不同 table 的论据（尽管请参阅其他要点）。
- 如果行为的变化实际上是随机的，我会用一个 table 来显示结构，然后再用 1+ 个其他 table 来涵盖行为的差异（即linked 到结构 table).
组件 table 需要一个 parent_id 字段，让您找到给定事物的所有子项。您可能也想要一个关于此的索引 - 我假设您阅读组件结构的频率高于它的变化，因此索引的成本超过了它的好处。
向 MySQL table 添加索引的示例是 in this other SO question.
另一件需要考虑的事情是在每个节点上放置一个级别计数器。 IE。组件是级别 1，子组件是级别 2 等。这将使一些工作更容易，例如，如果你想用不同的颜色或类似的东西来呈现级别。但如果你只是想要一棵无差别的事物树，那可能不值得。
关于 queries on hierarchical data in MySQL (there is more than one way to do it, with corresponding small differences in the table structure). Different database vendors give you different amounts of support for this kind of query, which makes it more or less easy. Oracle, for instance, has a very nice way to do hierarchies 的细节还有其他问题。
如果您确实选择单个 table，则不同 table 之间的 link 和用户的喜好就是 Polymorphic Association 的一个示例。 （这是一个 SO 问题的 link，它又对另一个问题有一个 link - 两者都很有用。）