php - 需要一些关于数据库模式设计的建议

Question

我正在设计一个非常简单(就功能而言)但困难(就可扩展性而言)的系统，用户可以在其中相互发送消息。把它想象成一个非常简单的聊天服务。用户可以通过 php 页面插入消息。该消息很短并且有收件人姓名。

在另一个 php 页面上，用户可以一次查看所有发送给他的消息，然后在数据库中删除它们。就是这样。这就是该系统所需的所有功能。我应该如何设计这个(从数据库/PHP 的角度来看)？

到目前为止我有这样的表:

• field1 -> 消息(varchar)
• 字段 2 -> 收件人 (varchar)

现在对于 sql 插入，我发现无论数据库中的行数如何，它所花费的时间都是恒定的。所以我的 send.php 将有一个有保证的返回时间，这很好。

但是对于下拉消息，我的 pull.php 会随着行数的增加而花费更长的时间!我发现随着行的增长，sql 选择(和删除)将花费更长的时间，即使在我为收件人字段添加索引之后也是如此。

现在，如果只是用户需要等待更长的时间才能将他们的消息拉到 php 上，那么就可以了。但我担心的是，当每个 pull.php 服务时间非常长时，php 服务器将开始拒绝连接某些请求。或者更糟的是服务器可能会死掉。

所以问题是，如何设计它才能扩展？任何提示/提示？

附言。对数字的一些估计:

• 用户数量从 50,000 开始并不断增加。
• 在另一端可能将其拉下之前，每个用户平均存储了大约 10 条消息。
• 每个用户每天发送大约 10-20 条消息。

---

到目前为止阅读答案的更新:

我只是想澄清一下，从 pull.php 中拉取更少的消息并没有帮助。当表很大时，即使只是拉一条消息也会花费很长时间。这是因为该表包含所有消息，因此您必须像这样进行选择:

select message from DB where recipient = 'John'

就算改成这样也没用

select top 1 message from DB where recipient = 'John'

到目前为止，从答案来看，表格越长，选择速度越慢，O(n) 或稍微好一点，没有办法绕过它。如果是这样，我应该如何从 php 端处理这个问题？我不希望 php 页面在 http 上失败，因为用户会感到困惑并最终疯狂地刷新，这使情况变得更糟。

Answer 1

正如您所建议的，数据库设计很简单。就用户收到更多消息后花费更长的时间而言，您可以做的只是对结果进行分页。显示前 10/50/100 或任何有意义的内容，并且只提取这些记录。一般来说，除非消息量增加一个数量级或更多，否则您的时间不应增加太多。您应该能够在不到一秒的时间内撤回 1000 条短信。现在，页面可能需要更多时间才能显示，但这正是分页应该提供帮助的地方。

我建议您仔细研究并考虑 future 的功能，并在此基础上进一步构建您的数据库。向软件添加更多功能很容易，更改数据库则相对困难。