徽章 - 数据结构/模型？
我试图弄清楚如何设置数据库和/或模型来处理各种徽章。让我们以 Stack Overflow 徽章 为例。每个规则都有不同的规则，有些可能只是变量不同（例如 10 条评论与 100 条评论）。
我的问题是如何在应用程序中设置这种类型验证/检查？每个徽章应该有自己的方法吗？
I'm trying to figure out how one would set up a database and/or model in order to handle various badges. Lets take the Stack Overflow badges as an example. There are different rules for each and some might be just a variable different (like 10 comments vs 100 comments).
My question is how do you set up this type validation/check within an application? Should each badge have its own method?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于 SO 是在 SQL Server 上运行的，因此 SQL Server 代理作业会定期运行以对统计数据进行制表。当满足条件时，作业中的存储过程将插入到徽章/等表中。
触发器是另一种选择，但它们的执行不能因多个用户的范围而延迟。
Being that SO runs off SQL Server, SQL Server Agent Job to run periodically to tabulate statistics. The stored procedure(s) in the job would insert into a badges/etc table when criteria is met.
Triggers would be another option, but their execution can't be delayed for the scope of multiple users.
如果需要的话，这就是我将如何实现它：
我将设置一些队列管理器（有很多这样的软件）并编写一个代理，它将处理来自队列的消息。
每次发生任何事件时，例如：您查看了某个主题、您编辑了您的评论、您编辑了您的答案、您编辑了另一个人的答案、您投了赞成票等等 - 您会再收集一条带有事件描述的消息。是的，那里会有确实大量的消息。
收集大量消息后，您可以启动一个代理来按计划或实时处理消息。
使用此架构，您可以将代理扩展到您想要的复杂徽章。
That is how I would implement it if I need to:
I'll set up some queue manager (there are a lot of such software) and write a broker, that will process the messages from the queue.
Each time any event occurs, such as: You viewed a topic, you edited your comment, you edited your answer, you edited another person answer, you upvoted, etc etc - you collect one more messages, with event description. Yes, it will be really huge amount of messages there.
After you collect that huge amount of messages - you can start a broker that will process messages by schedule or in real time.
With this schema you could extend a broker to as complex badges as you want.
我想有些是实时计算的，而另一些是在间歇运行的进程中计算的。
例如，对于当您的答案获得 10 票赞成时出现的徽章，可以实时计算，对性能影响很小。
另一方面，对于检查您是否达到每日声誉上限 x 次的徽章，您可能希望将其作为某种批处理作业来执行，因为您只在每天结束时进行检查。
关键问题是保持事物快速运行。 Stack Overflow 每天会收到数千（也许数万）个问题，可能还有数十万条评论。任何计算不简单的事情都应该在单独的进程中运行。它使核心功能保持紧凑、有限和干净，从而实现高性能。在核心发布系统之外的进程中运行复杂的计算使您可以在不影响用户使用网站的能力的情况下执行此操作。如果任务足够复杂，您可以通过在多台机器上运行相同的进程来水平扩展。
I would imagine some are calculated realtime, while others are calculated in processes that run intermittently.
For example, for the badge that appears when your answer gets 10 upvotes, that could be calculated realtime with little performance hit.
On the other hand, for the badge that checks if you hit the daily reputation cap x number of times, you would probably want to do that as some sort of batch job, since you only check at the end of each day.
The key concern is to keep things running fast. Stack overflow gets thousands (maybe tens of thousands) of questions a day, with probably hundreds of thousands of comments. Anything that is not trivial to calculate should be run in a separate process. It keeps the core functionality tight, limited, and clean, allowing high performance. Running complex calculations in processes outside the core posting system allows you to do so without affecting users' ability to use the site. If a task is sufficiently complex, you can scale horizontally by just running the same process across multiple machines.