数据库设计，用于越来越多的数据(30,000+项，每天得到48个新的更新)

Question

我想显示游戏中商业项目的历史数据(和当前数据)。数据是现成的，我只想确定存储数据的最佳方式以提高性能。

基本上我想要储存：

• 卖价
• 收购价
• 可得数量
• 订购量

...48时间每天，每项，与数万项。

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

你将如何构造这个数据库？

Answer 1

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

为了减少数据的数量，只有记录更改--任何特定项的数据在一周内都不会改变，那么为什么要创建将近350个记录呢？

不太确定你的游戏机制是什么(很明显)，但是历史数据会很重要吗？你能把上周的价值放在“活”表上，然后把历史数据移到历史表上吗？可能是一个包含当前数据的“当前”表，每当该数据发生更改时，将该项的旧数据移动到历史表，并创建新的“当前”记录，其“时间戳”为“now”。

记录每个文件的结构

• item#
• 日期戳
• 雷姆(Autoinc)
• 塞尔普莱斯
• 买价
• 质量效益
• 数列

粗体辅助键中的主键: recnum，item# (可能)

Recnum是当前表上的autoinc，在历史记录中是整数。

当一个新记录被添加到当前表中时，它将获得一个recnum (nextnum)和datestamp of (now)，而item#的当前记录将完全按照原样移动到历史表中。通过这种方式，您可以控制客户端计算机上保存的历史表的加载，如果您存储最高的recnum --所有自以来具有较高内存的所有更改。通过在密钥中添加“感兴趣项”，您可以限制所需传输的数据量--如果任何特定玩家(或100或1000)感兴趣的只有10项，那么您不需要将剩余的数据转移给它们--直到他们对新项感兴趣时，您就可以使用索引单独传输该项目的数据了。