Database 针对越来越大的数据量（30000项，每天更新48项）的数据库设计

我想在游戏中显示商业项目的历史（和当前）数据。数据随时可用，我只想确定存储数据以提高性能的最佳方式

基本上我想储存：

• 售价
• 买入价
• 可用数量
• 订购数量

…每天48次，每件商品，成千上万件商品

我没有存储这种不断增长的数据的经验。我曾考虑为每个项目（PHP和MySQL）设置一个序列化数组，但这似乎是一个可怕的解决方案

---

您将如何构造此数据库？

您还需要时间戳和项目编号，因为这是一个游戏，请使用简单的整数-将时间戳除以48得到日期和时间，以美分为单位的价格（不要使用浮点）

为了减少数据量，只记录变化——任何特定项目的数据可能在一周内不会发生变化，那么为什么要创建近350条记录呢

不确定你的游戏机制是什么（很明显），但历史数据会有意义吗？你能在一张“实时”表格中持续说出上周的价值，并将历史数据移动到一张历史表格中吗？也许一个“当前”表正好包含当前数据，每当该数据发生更改时，将该项的旧数据移动到历史表中，并创建一个“时间戳”为“现在”的新“当前”记录

---

记录每个文件的结构

• 项目#
• 邮戳
• Recnum（汽车公司）
• 售价
• 买价
• qtyavail
• qtyordered

主键为粗体 辅助键：recnum，项#（可能）

Recnum在当前表中为autoinc，在历史记录中为integer

---

将新记录添加到当前表时，它将获取recnum（nextnum）和datestamp（now），并且项#的当前记录将准确地移动到历史记录表中。通过这种方式，如果存储最高的recnum（自以来具有较高recnum的所有更改），则可以控制客户端计算机上保存的历史记录表的加载。通过将感兴趣的项目添加到密钥中，您可以限制需要传输的数据量-如果任何特定玩家只对十个项目感兴趣（或一百个或一千个），那么您不需要将剩余的数据传输给他们-直到他们对新项目感兴趣，当您可以公正地使用索引单独传输该项目的数据时。

因此，这大约是每天140万行，或每月4300万行，或每年5.18亿行。是这样吗？你确定你真的想要一个游戏的细节吗？我知道这听起来有点过分。有多个网站正是这样做的，同一个游戏有相同的数据。我怀疑他们每天都会增加那么多行，所以可能有一个更优雅的解决方案。谢谢Magoo。确实有可能有一个历史表格。您会为历史表格推荐什么样的结构？目标是在图表中显示数据。