3

我正在构建一个应用程序，我将从游戏中收集统计数据。本质上，我将解析每行都是游戏事件的日志。大约有 50 种不同类型的事件，但其中很多是相关的。每个事件都有一组与之关联的特定值，并且相关事件共享许多这些属性。总的来说，大约有 50 个属性，但任何给定的事件只有大约 5-10 个属性。

我想使用 Rails 作为后端。大多数查询将与事件类型相关，这意味着我并不特别关心两种事件类型在任何给定轮次中如何相互关联，就像我关心来自多个轮次的单个事件类型的数据一样。我应该构建什么样的架构，应该使用什么样的数据库？

给定一个关系数据库，我想到了以下几点：

  1. 具有扁平结构，其中只有几个表，但事件表的列数与总体事件属性一样多。这会导致每一行都有很多空值，但它可以让我轻松访问我需要的内容。

  2. 除其他事项外，为每种事件类型设置一个表格。这可以让我节省空间并提高性能，但考虑到事件并不是真正独立的“想法”，拥有这么多表似乎有些过分。

  3. 将相关事件组合在一起，最大限度地减少表格数量和每个表格的属性数量。那么问题就变成了分组。它远非明确，正确建立事件超类型可能需要很长时间。此外，它并不能完全解决存在大量 nil 的问题。

也有人建议我考虑使用 NoSQL 数据库，例如 MongoDB。在这种情况下似乎非常适用，但我以前从未使用过非关系数据库。似乎我仍然需要很多不同的模型，即使我不会为每个模型设置表格。

有任何想法吗？

4

1 回答 1

1

这对于 MongoDB 来说是一个很好的用例，但对于关系数据库来说却非常尴尬。

您将对这些数据进行的查询类型对于最佳模式设计非常关键，但想象一下您的文档（在类似于上面 1. 的单个集合中）看起来像这样：

{  "round" : 1,
   "eventType": "et1",
   "attributeName": "attributeValue",
   ...
}

您可以轻松地按轮次、按事件类型、取回所有属性或仅指定子集等方式进行查询。

您不必预先知道您可能拥有多少属性，哪些属性属于哪些事件类型，甚至您拥有多少事件类型。在构建原型/应用程序时，您将能够根据需要改进模型。

有一个非常大的 Rails/MongoDB 人员活跃社区，您很有可能会找到很多可以提出问题的开发人员和很多可以作为示例查看的代码。

我鼓励您尝试一下，看看它是否适合。我打算添加一些链接来帮助您入门，但是可供选择的链接太多了！由于您可能对是否使用对象映射器有疑问，所以这里有一个很好的答案。

这里有一篇关于使用 Ruby 和 MongoDB 处理动态属性的好文章。

于 2012-06-02T03:07:10.727 回答