我正在开发一个在线游戏的爱好项目。该游戏将玩家数据存储在一个大平面文件中。数据本身包含玩家从名称到玩家本身甚至物品的所有信息。它本身就是一个相当大的列数，只有几十个项目才会增加平面文件的大小。
为您提供视觉效果。我当前的播放器文件是192列（不考虑项目）。
在减少绒毛之后，我的平面文件中有51列用于播放器数据。这不包括玩家的物品或能力。我已经决定将这些表分成单独的表并与FK链接。
51列数据对于播放器是唯一的，不应重复。他们不是我被告知的正常化的良好候选人。
但是，选择和更新其中某些列的活动彼此之间存在很大差异。有些是在玩家移动时更新的，有些则在玩家登录游戏并加载到内存中时很少使用。记录永远不会被删除或重建。每列都有一个值。活动频率从每秒到每月一次。
这引出了一个问题。如果它们位于同一个表中，我可以根据活动拆分这些列而不是传统的数据规范化方法吗？或者我应该把它们放在同一张桌子上，只是依靠正确的索引？大多数列看起来都不错，但正如我所说，有些列比其他列使用得更多。但是，当某些用途比其他用途更多时，存在巨大差异。这让我害怕。
答案 0 :(得分：1)
你所提到的被称为denormalization，实际上是一个众所周知且频繁的事情。
关于何时进行非规范化，没有一般规则和指示。 这取决于每个项目特定的许多内容（例如硬件，数据库类型以及您提到的“活动”），它归结为分析每个应用程序以得出结论。
此外，有时非规范化意味着将表拆分为两个具有一对一关系的表（如您的情况）。有时它意味着摆脱FK并将所有内容放在一个包含许多列的BIG表中，以避免在选择时出现连接。
最重要的是，请记住，您的问题与可扩展性相比，性能更多。分离到不同的表/数据库意味着您最终可以将数据存储在不同的计算机中，每台计算机都具有特定的硬件体系结构，其中包含适合用例的数据库。
关于MMORPG，我可以想到的非规范化的一个例子是将所有不经常更改的用户数据存储在BLOB中。这不仅是非规范化的，而是整行存储为一系列字节。 Dr. E.F. Codd根本不会高兴。
执行此操作的公司是Playfish。
这意味着您更快以更慢更新为代价进行选择，最重要的是，更改用户的架构变得非常麻烦（但这里的推理在时间结束之前它始终是Username，Password，E-mail。这也意味着您的用户数据现在可以存储在更简单的键/值存储中，而不是具有更多开销的RDBMS。当然，获取用户信息的登录服务器不需要像处理游戏玩法的那样高效。
因此，请尝试阅读非规范化的用例（这是一个非常活跃的主题），并了解您可以在案例中应用您的发现的位置。另外，请记住，预优化有时会适得其反，也许您现在应该专注于开发游戏。当您遇到扩展/性能问题时，您很可能会获得大量用户提供的资金来解决问题。祝你好运！