为尚未阅读该主题的用户存储论坛的价值(这是一个坏主意)将无法扩展。如果确实需要,可以 用另一种方法来做 ,因为您还将遇到与新用户注册后必须向
数据库中的每个主题 添加条目相关的问题。
代替前面的关系表,请尝试如下进行 *** 作:1
Table: topics+----+-------+------+-----| id | title | body | ...+----+-------+------+-----| 1 | xyz | .... | ...Table: replies+----+-------+------+-----| id | title | body | ...+----+-------+------+-----| 3 | xyz | .... | ...Table: read_topics+---------+----------+| user_id | topic_id |+---------+----------+| 2 | 1 |
当您拥有大量用户时,您的方法虽然可能(并且更容易想象)开始崩溃,但是可伸缩性是您在注释中提到的。这里的另一个问题是,采用这种方法会造成 巨大的
性能损失,因为在进行另一笔交易之前,您必须从数据库中提取数据,对其进行拆分,然后进行 *** 作和重新组合。您还存在 同时由两个CGI线程写入表的
问题。玩的开心…
您正在使用一种用于数据 *** 纵,排序,数据关系和存储的工具,因此将其用于所有工具,而不仅仅是作为信息的垃圾场。
1.我距离数据库优化的专家还很遥远,很可能有比这更好的方法。测试!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)