2

我计划一个角色扮演游戏，角色应该携带/使用物品并训练技能。当谈到存储（可能很多）角色拥有的物品/技能时，我想不出比为每个实例化的每个角色放置每个可能的物品和技能更好的方法了。然而，这对我来说似乎有点过头了。

需要明确的是，如果这将是一个项目/技能总数约为 30 的练习或小型游戏，我会在角色类中添加一个项目和一个技能哈希，以及添加和删除它们的方法，例如：

def initialize
  @inventory = {}
  @skills = {}
end

def add_item item, number
  @inventory[item] += number
end

关于我想存储物品的数量和技能的等级，我还能尝试处理〜1000个物品和〜150个库存，可能还有100个技能？

4

2 回答 2

3

数据检索计划

通常，围绕您计划如何查找和检索数据而不是如何存储数据来设计数据库是一个好主意。糟糕的设计会使您的数据从数据库中收集起来非常昂贵。

在您的示例中，每当您想要加载角色时，对于每个库存项目或技能都有一个单独的模型在查找方面会非常昂贵。您真的想在每次加载某人的库存时进行 1,000 次查找吗？可能不是。

非规范化速度

您通常希望对需要一致的数据进行规范化，并对需要快速检索/更新的数据进行非规范化。一种选择可能是序列化您的角色属性。

例如，存储序列化的 Character#inventory_items 字段应该比使用has_many :thoughorhas_and_belongs_to_many关系更新 100 条单独的记录更快。在一般的非规范化和特别是序列化方面肯定存在权衡，但它可能非常适合您的特定用例。

考虑一个文档数据库

字符表是文档。除非您需要 SQL 数据库的关系功能，否则面向文档的数据库可能更适合您要管理的数据。CouchDB 似乎特别适合这个示例，但您当然应该评估所有 NoSQL 选项，看看是否有任何提供您需要的功能。您的里程肯定会有所不同。

始终基准

不要相信我的话是最佳的。尝试设计。对其进行基准测试。查看设计如何处理您的数据。最后，这是唯一重要的事情。

于 2012-07-18T21:45:00.120 回答
1

我想不出比为每个实例化的每个角色的每个可能的项目和技能放置一行更好的方法了。

角色会独立进化吗？

  • 假设是，除了让每一端的每个相关组合物理表示在数据库中之外，别无选择。
  • 如果没有，那么您可以为多个角色“重复使用”相同的套装或物品/技能，但这可能不是这里发生的事情。

无论如何，关系数据库非常擅长管理大量数据，您提到的数字甚至不符合“巨大”的条件。通过正确利用诸如集群之类的技术，您可以确保以最少的 I/O 操作（即非常快）查找给定角色的所有项目/技能。

于 2012-07-18T22:30:33.860 回答