PHP 驱动的详尽统计数据 - 服务器端文本文件或 MySQL 表？

Question

我有一个拥有 200 多名用户的游戏网站。该网站拥有跟踪用户游戏的大型数据库，持续参与的动机之一是网站为用户提供的广泛统计数据和排名 (S&R)。

随着跟踪的 S&R 列表的增长，一些更复杂的计算已移至数据库内的表中，而不是即时生成，以提高页面加载速度。

不过，我计划在今年年底前从广泛的 S&R 转向详尽的 S&R，将用户可用的数据点总数增加 10 倍。我已经决定停止进行即时查询并将所有计算移至 cron 作业，但我不确定在哪里存储数据。

给定用户基数<1000，将这些数据放入数据库或为每个用户的统计数据读/写一个文本文件是否更有意义？

这些是我认为的主要优点和缺点：

在数据库中存储 S&R

+ cross-user comparisons are easy and fast
+ faster cron jobs because there's no need to write to many, many files
- database table count will jump from ~50 to 200+ (at least)
- one point of failure (database corruption) for all site data
- modifying S&R structure requires modifying database as well

在文本文件中存储 S&R

+ neatly organized and distributes data corruption risk
+ database is easier to navigate
+ redesigning S&R structure is done by simply modifying script and 
  overwriting all text files, rather than adjusting database tables
- cron job will have to read/update XXX files each time
- cross-user comparisons are difficult and time-consuming

但我以前从未做过如此大规模的事情，所以我不太确定（例如）200+表的MySQL数据库是否真的是一个问题？

如果您能提供任何建议，我将不胜感激！ :-)

Answer 1

任何流行的数据库软件都应该能够处理数百万个条目，拥有 200 多个表在这方面不是问题。

损坏的可能性不大，但在这种性质的站点上，您应该相当频繁地进行备份，并且最好在服务器外部存储副本 - 使用单个文件进行分发并减少一般故障的可能性，但也有很小的可能性发生问题。

数据库软件擅长对其数据执行任务，使用平面文件可能会迫使您编写自己的方法来处理它们，这很容易被证明是一项主要任务，但与使用平面文件相比，会损失速度的额外成本数据库（我只是假设这一点，我可能是非常错误的）。