我正在从事一个业余项目，即在线游戏。该游戏将玩家数据存储在一个大的平面文件中。数据本身包含了玩家的所有信息，从名字到玩家本身的元素。它本身就是一个相当大的列，拥有数十个项目只会增加要引导的平面文件大小。
给你一个视觉效果。我当前的播放器文件是 192 列(不考虑项目)。
玩家数据
在我减少绒毛后，我的播放器数据平面文件中有 51 列。这不包括玩家的元素或能力。我已经决定可以将它们分成单独的表并与 FK 链接。
这 51 列数据是播放器独有的，不应重复。他们不是我被告知的正常化的好候选人。
表格
- 编号
- 姓名
- 密码
- 种族
- 性别
- 类
- 等级
- 金牌
- 白银
- 经验
- 追求
- 盔甲
- 力量
- 智慧
- 灵巧
- 等等
事件
但是，选择和更新其中一些列时的事件彼此之间有很大不同。有些会在玩家移动时更新，有些则很少在玩家登录游戏并加载到内存时使用。记录永远不会被删除或重建。每列都有一个值。事件频率从每秒一次到每月一次不等。
问题
这引出了一个问题。如果它们在同一个表中，我可以根据事件拆分这些列并提高性能，而不是传统的数据规范化方法吗？还是我应该将它们放在同一张表中并仅依靠适当的索引？大多数专栏看起来都不错，但就像我说的，有些专栏比其他专栏使用得更多。但是，当某些人比其他人使用得更多时，存在巨大差异。这有点让我害怕。
最佳答案
你说的是denormalization这实际上是一个众所周知且经常发生的事情。
没有关于何时去规范化的一般规则和指示。 这取决于每个项目特有的许多事情(例如硬件、数据库类型和您提到的“事件”等)，归结为对每个应用程序进行分析以得出结论。
此外，有时非规范化意味着将一个表拆分为具有一对一关系的两个表(就像您的情况一样)。有时这意味着摆脱 FK 并将所有内容放在一个包含许多列的 BIG 表中以避免选择时的连接。
最重要的是，请记住，与可扩展性相比，您的问题与性能同样重要。分成不同的表/数据库意味着您最终可以将数据存储在不同的机器上，每台机器都有特定的硬件架构和适合用例的数据库。
游戏行业的非规范化示例
当谈到 MMORPG 时，我能想到的一个非规范化示例是将所有不经常更改的用户数据存储在 BLOB 中。这不仅是反规范化，而且整行都存储为一系列字节。 Dr. E.F. Codd一点都不开心。
做这件事的公司是 Playfish .
这意味着您以较慢更新为代价获得了更快的选择，而且最重要的是，为用户更改架构变得非常麻烦(但这里的推理它总是Username, Password, E-mail 直到时间结束)。这也意味着您的用户数据现在可以存储在更简单的键/值存储中，而不是开销更大的 RDBMS。当然，获取用户信息的登录服务器不需要像处理游戏的服务器那样高效。
因此，请尝试阅读有关非规范化的用例(这是一个非常活跃的话题)，看看您可以将您的发现应用到您的案例中。另外，请记住，预优化有时会适得其反，也许您现在应该专注于开发您的游戏。当您遇到扩展/性能问题时，您很可能会获得大量用户带来的资金来解决该问题。祝你好运!
关于mysql - 我应该根据事件拆分表格吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18432060/