创建馈送墙

我相信Facebook等通过拥有一个单独的通用“更新”记录数据库来处理这个问题,这些记录对所采取的行动有一个简短的描述。每当有人在网站上执行应该显示在墙上的操作时,更新数据库中也会插入一条记录。

好的,这是你可以尝试的。。你不能把问题、答案和他们的评论放在同一张表格里。。一个问题可以有很多答案,不同的答案可以有不同的评论。把它们放在同一个表中会非常混乱,不建议这样做(违反RDBMS的规则)。制作三张独立的表格,一张用于提问,一张用于回答,一张用于评论。根据主键和外键定义它们之间的关系。。因此,在问题表中的任何时间点,您都有所有用户提出的所有问题。答案表将有对应于该特定问题的所有答案,评论表将有对应答案的评论。在所有表中维护适当的支持列,您可以轻松地管理所需内容。在任何时候,您都可以通过连接问答表查看与特定问题相关的所有答案,也可以通过连接问答表查看对特定答案的所有评论。。

希望这能给你一个主意。。

如果你要用一张桌子,你可能想试试这样的。

表{ 身份证件, 用户ID, 类型, 文本, }

这将在一个表中提供基本的树结构。

这样做的代价是,您可能会有更复杂的查询,并且可能需要更多的查询来实现您想要的。

确保在id列上至少有索引。

我仍然不确定你需要多大的表现。像facebook这样的网站必须考虑的不仅仅是表级优化。对于大多数站点,教科书关系模型可以比此模型更有效地进行查询。你的绩效目标是什么?

enter code here @我的假设是咬紧牙关,如果使用MySQL,那么就使用关系,或者如果您想完全摆脱带有关系的表,就移动到其他类型的数据库。您需要RDB模型的“干净”实现。对于RDB,我建议您使用四个表:用户、用户地图、问题和响应。回答是分类的(例如,对一个问题或答案),所以跟踪它是哪种类型,其中任何表中只有外键是Question.id和user.id。

Users: id, name
User_map (can be used with Questions and/or Responses to join the data): u_id, q_id
Questions: id, text_value
Responses: id, q_id, text_value, category

你是否真的认为人际关系是需要优化的,或者只是过度分析了?如果您需要摆脱基于关系的数据库,那么我建议您研究为其构建的技术。