我计划玩一个角色扮演游戏，让角色携带/使用物品并训练技能。当涉及到存储角色拥有的（可能是大量的）项目/技能时，我想不出比为每个可能的项目和技能给实例化的每个角色放一行更好的方法了。然而，这对我来说似乎有些过头了。
需要明确的是，如果这是一个练习或小游戏，项目/技能的总数约为30，我会在角色类中添加一个项目和技能哈希，以及添加和删除它们的方法，如：
def initialize
@inventory = {}
@skills = {}
end
def add_item item, number
@inventory[item] += number
end
关于我想存储物品数量和技能等级，我还能尝试处理库存中的1000件物品和150件物品，以及可能的100项技能吗？
数据检索计划
一般来说，围绕您计划如何查找和检索数据而不是如何存储数据来设计数据库是一个好主意。糟糕的设计会使从数据库中收集数据的成本非常高。
在您的示例中，每当您想要加载角色时，为每个库存项目或技能创建一个单独的模型在查找方面会非常昂贵。你真的想每次加载某人的库存时进行1000次查找吗？可能不会。
速度的非规范化
您通常希望规范化需要一致的数据，并取消规范化需要快速检索/更新的数据。一种选择可能是序列化您的角色属性。
例如，存储序列化的Character#inventory_items字段应该比使用has_many :though或has_and_belongs_to_many关系更新100个单独的记录更快。通常情况下，反规范化和序列化肯定会有一些折衷，但它可能非常适合您的特定用例。
考虑文档数据库
字符表是文档。除非您需要SQL数据库的关系能力，否则面向文档的数据库可能更适合您想要管理的数据。CouchDB似乎特别适合这个例子，但您当然应该评估所有的NoSQL选项，看看是否有提供您需要的功能。你的里程肯定会有所不同。
始终基准
不要相信我的话是最佳的。试试设计。对其进行基准测试。查看设计对您的数据的作用。最后，这是唯一重要的事情。
我想不出比为每一个可能的项目和技能给每个实例化的角色放一行更好的方法了。
角色是独立进化的吗？
- 假设是，除了在数据库中物理表示每个相关组合之外，别无选择
- 如果没有，那么你可以为多个角色"重用"相同的集合或项目/技能，但这可能不是这里发生的事情
在任何情况下，关系数据库都非常善于管理大量数据，而您提到的数字甚至不符合"巨大"的条件。通过正确利用聚类等技术，可以确保在最少的I/O操作中（即非常快）完成给定角色的所有项目/技能的查找。