设计一个徽章系统，在哪里触发业务逻辑?在代码或存储过程中?或两者? [英] designing a badge system, where to fire business logic? In code or stored procedures? or both?

问题描述

如果您要构建一个类似于 SO 的徽章系统，您是将逻辑/业务层直接放在数据库中(通过存储过程、预定的 sql 作业)还是放在服务器端?

If you were to build a badge system similiar to how SO does it, would you put the logic/business layer in the database directly (via stored procedure, scheduled sql jobs) or put it in the server side?

据我所知，你必须:

1. 列出与当前用户操作相关的徽章
2. 检查用户是否已经拥有徽章
3. 为用户插入徽章

潜在选择

1. Web 应用程序中调用存储过程等的业务逻辑.
2. 仅限存储过程
3. 每 x 分钟运行一次的 sql server 作业
4. 每 x 分钟运行一次的 windows 服务

是否需要将这些组合在一起?我认为由于某些徽章基于给定问题的里程碑，也许批处理作业更好?

Would a combination of these be required? I think it would since some badges are based on milestones for a given question, maybe a batch job is better?

更新

一个可以修改徽章系统，然后为每个人重新运行整个徽章链接的系统会更好.即假设您更改了某些徽章的逻辑，现在您必须将其重新应用于所有问题/答案/投票/等.

A system where you can modify the badge system, then re-run the entire badge linking for everyone would be even better. i.e. say you change the logic for some badges, now you have to re-apply it to all the questions/answers/votes/etc.

要解决的有趣问题！！

推荐答案

我建议将所有业务逻辑放在业务层中.我推荐这个有几个原因:

I would recommend putting all business logic in the business layer. I recommend this for a few reasons:

• 将业务逻辑合二为一语言/地点
• 可扩展性 -您可以对数据进行分区，实现不同的缓存机制等
• 关注点分离 - 让您的数据库尽其所能……存储数据，让您的编程语言对该数据做出决策.

这篇关于设计一个徽章系统，在哪里触发业务逻辑?在代码或存储过程中?或两者?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！