基于点的Rails中类似堆栈溢出的系统设计

Question

我没有试图重新创建Stack溢出，我确实看过类似的问题，但它们没有多少答案。

我感兴趣的是如何设计一个rails应用程序，特别是模型及其关联，以便捕捉各种不同类型的动作及其点数。此外，这些点会随着时间的推移而衰减，并且有可能以我正在跟踪的其他操作或其他数据的形式进行修改。

例如，如果我正在设计Stack溢出(这也不是)，它会发生如下情况。

创建一个问题=5 points

• Answering一个问题=10分

• 所选的正确答案是回答问题点上的x2修饰符。

从设计的角度来看，在我看来，我需要3种型号的关键部件。

动作模型是多态的，因此它可以属于问题、答案或其他什么。关联的类型存储在类型字段中。它还包含一个点字段，它是在创建时通过查找点模型来计算的，我将在下面讨论。它还应该更新用户模型上的总分，我将在这里不讨论这个问题。

points 模型是一个查找表，在该表中，操作可以计算出它们的点。它使用操作类型作为键。它还存储点的数量和衰减的字段。

修饰符模型是我不知道该如何处理的模型。我认为它可能也应该是一个查找表，类似于使用操作的类型字段的点。此外，它还需要一些条件，什么时候应该应用它。我不知道如何存储条件语句。它还需要存储如何修改点。例如，x2，+5，-10，/100等等。另一个问题是修饰符是如何在操作已经发生之后被应用的。在我的例子中，这将是当一个问题被选择作为答案。到这个时候，分数已经设定好了。我能想到的唯一方法就是在每个可能是修饰符的模型上都有一个after_save，该修饰符检查修饰符表并应用它们。但对我来说，这似乎是不对的。

还有其他的问题，如如何处理衰变。我想我需要一份只需要重新计算每个人的分数的cron工作，但这似乎不是很好。

我不知道我是不是想得太多了，但我想要一些反馈。

Answer 1

我倾向于使用日志聚合快照记录离散事件，然后定期聚合更改并将它们存储在单独的表中。这将允许您以插入作业而不是更新作业的形式处理诸如衰变之类的事情。取决于有多少选票，你甚至可以随着时间的推移把它们聚合起来，只从一个特定的点向前滚动(虽然每个问题或答案可能不足以引起关注)，但考虑到你可能还有其他的事情，比如用户的总分，这可能是快照的好东西。

不过，我认为您需要了解如何处理衰变，然后才能在聚合快照表中处理它。

Answer 2

现在Rails拥有了gem来实现这一功能。

https://github.com/tute/merit