Question

我需要一些关于如何构建我的数据库的建议。我将告诉你一个如何运作的一般例子。

因此该网站将拥有数千名用户 - [1位用户提供他们的详细信息我猜 - 好在这里]

让我们说每天都会有一些管理员发布的问题/事实，用户可以选择答案，例如1,2,3。每个用户都可以在每个问题上选择一个答案 [1表有问题我想 - 或许问题可以是单独的表，取决于月份或年份？]

每个对特定问题进行选择的用户，例如问题/事实＃54，都会存储他的答案。所以一个简单的想法是有一个新表来存储它。例如user1和问题＃54，回答1.

但如果用户数以千计，那么想象每天30-40个问题/事实*数千个答案*天/年等等。我想这太慢了。

另一个想法是为每个用户创建一个表，但我认为这真的很糟糕

想象一下，我需要检索答案的历史记录，并且非常快速地在其他模块上使用这些数据。拥有数百万或无限条目的表作为年份通过将是不好的搜索，对吧？

表设置将是少量写入，实际上很多读取。因为整个站点都需要读取。对于具有最成功答案的用户。您个人资料中所有答案的历史记录。每个类别的问题都有正确答案的热门用户（我忘了说的不同类别的问题 - 所以每个类别的新表格大约是5-10个或类似的类别数量）也是每月和每年的统计数据。过去几年将只是因为他们的个人资料的历史目的所以没有那么多读。（所以也许类别每年都有表格？）它的全部内容都是关于每个用户的统计数据。

所以我的问题是你认为我应该如何建立这个？

提前致谢

我愿意接受更多想法。还忘了问php + mysql还是aspx + mssql？

Answer 1

我要考虑的是提供问题表和答复表每个问题都有自己的唯一ID，也会出现在响应表中。

QUESTIONS的示例布局为：QUESTION_ID, TEXT, RESPONSE_VALUES，RESPONSES的示例布局为QUESTION_ID, USER_ID, RESPONSE_ID。

这种关系被称为“foreign keys” 您也可能希望了解“一对多”关系。

Answer 2

通常，在查询具有数百条记录的表时，设计良好的数据库大致同样快，因为查询具有数千条记录的表时 - 只要您可以使用索引访问数据。

另一方面，一旦您需要之前进行性能优化，维护成本会很快上升。

因此，我建议您将数据库设计为易于理解的开发人员，编写性能测试，并且只在您真正需要时才进行优化。

至于你的具体问题：

Table USERS
user_id (primary key)
name
...

table QUESTIONS
question_id (primary key)
question_date
question_text

table ANSWERS
answer_id (primary key)
question_id (foreign key to questions)
answer_text

table user_answers
user_id (foreign key to users)
answer_id (foreign key to answers)
is_correct_flag

在所有键上创建索引，并且（可能）为question_date;如果您需要按用户名搜索，也可以在该列上创建索引。

现在用SQL编写数据访问查询 - 不必完全正确，只需要让你测试就好了。然后使用测试数据生成器来填充表 - 我过去使用过DBMonster。将数据放入数据库中的数量是您预期的两倍。

现在执行数据访问查询，并测量响应时间。这样做几次，按照不同的顺序 - 数据库上的缓存等可能会产生误导性的结果。我发现使用单元测试框架（如PHPUnit）封装它们很有用 - 这样，您可以多次重新运行相同的测试。

如果你很幸运，你根本不会遇到任何性能问题。如果不是，请使用EXPLAIN来优化查询。如果这不起作用，请考虑获得更好的硬件。如果这不起作用，则创建预先计算的“报告表”，将通常请求的数据聚合成一个简单的扁平结构，并在批处理或数据更改时进行更新。

例如，如果您必须报告一段时间内的用户分数，您可以创建一个表格

table USER_SCORE_PERIOD_REPORT
user_id
username
period
score

我喜欢坚持命名约定，以确保明确识别这些“报告表”，而不是错误的常规“事务”表。

但实际上，只有当你知道自己遇到性能问题时才会这样做 - 这个解决方案会创造出更多可以破解的东西，并有更多的机会来处理漏洞。

需要mySQL建议 - 如何构建特定的mysql数据库/架构 - 示例里面

2 个答案: