我开始考虑我的新项目，我发现了一些速度问题，所以我希望你能帮我选择一种优雅而优雅的编码方式。
每个用户在数据库中都有他访问过的“地点”的记录。每个地方都有“学校” - 这个地方有很多学校。每所学校都有课程。每个班级可能会在不同时间结束其“学习年度”，因此如果日期>> =学年结束，则该数字应该递增。
所以我们有这样一个数据库：
“places”表：
place | user_id |
-----------------
1 | 4 |
2 | 4 |
用户4号访问过1号和2号地方
“学校”表：
school | place |
----------------
5 | 2 |
6 | 2 |
地方2有两所学校 - 身份证5和6。
“班级”表：
class | school | end_learning | class_number
---------------------------------------------
20 | 5 | 01.01.2013 | 2
21 | 5 | 03.01.2013 | 3
22 | 5 | 05.01.2013 | 4
学校5有3个班级，其中ID为20,21,22。如果日期大于01.01.2013，则班级20的班级编号应增加到3，结束学习日期更改为01.01.2014。等等。
现在我们遇到了问题 - 如果有1000个地方，每个地方有100所学校，每个学校有10个班级，我们有100万个记录。这是很多。因为我所提供的只是一个简单的例子，所以每次用户刷新页面时我都要考虑更新整个数据库，所以我担心这些记录可能会有些滞后。
我也可以将课程序列化到学校表中的一个字段：
school | place | classes
-------------------------------------------------------------------------
5 | 2 | serialized class 20, 21, 22 with end_learning field and class number
6 | 2 | other serialized classes from school 6
在这种情况下，我得到的记录减少了10倍，但每次我必须反序列化数据，检查日期以及是否比现在更改它，序列化并保存到数据库。第二个问题是我必须从db中选择所有记录来操纵它们，而不仅仅是所有需要改变的记录。
我也在考虑拥有两个数据库：一个记录可能需要在将来进行更改，另一个可能需要在接下来的24小时（不久的将来）进行更改。每隔24小时，在接下来的24小时内结束学习的所有课程都将移至“不久的将来”数据库，因此每次刷新页面都可以处理数千条记录，而不是数十万或数百万条记录。而不是它在数百万条记录（未来的未来）上工作，每天只创建一次“近期”表。
您如何看待所有这些数据库模式？也许你有更好的主意？
答案 0 :(得分：2)
我不太了解您概述的业务逻辑或数据模型 - 但我会假设您已经考虑过这一点。
首先，像MySQL这样的RDBMS解决方案确实非常擅长管理大量记录，只要您使用的数据是关系型的。据我所知，你将搜索许多记录，但只更新一些（用户只会注册有限数量的类）;我不认为这是个大问题。
其次，使用“标准”关系模型几乎总是更好，直到你能证明它不能满足你的性能需求，而不是在开始时选择“异国情调”的解决方案（我对你的序列化和分区解决方案进行分类作为这个答案的目的的“异国情调”）。大量的时间和精力已经用于优化SQL的性能;如果有一个简单的替代方案，它将成为标准解决方案的一部分。当然，标准关系模型不能扩展的点（例如Facebook大小的流量），或者关系模型不适合的业务领域（文档，图形）。但是，所有替代方案都有其优点和缺点，就像“标准”MySQL一样。
第三，处理可能的性能问题的最佳方法是处理它们。在代码中。构建测试装备，根据关系模型创建模式，用测试数据填充它（例如使用DbMonster），向其投入一些负载（例如使用JMeter）并调整模式和查询证明您的情况不符合标准解决方案。如果你真的可以证明你不能在标准的关系数据库中发挥出色，那就去寻找异国情调。