相关疑难解决方法(0)

匆匆-问题:

总而言之,我对如何设计这样一个允许无限制徽章规则创建而不需要对数据库中以前存在的用户表进行结构更改的数据库感到困惑.

存储徽章标题,标准等.该表的外观如何？

• badge_id(1)
• badge_title(10K徽章)
• badge_image(10k.jpg)
• badge_criteria([posts]> = 10000)
  ...

啰嗦,问:

我想在我自己的个人项目中实施徽章系统,但我正在寻求一些关于如何最好地做这样的事情的建议.我一直在阅读有关徽章系统的一些问题,但没有看到数据库架构受到太多关注.

基于用户点的徽章(假设的"10k徽章")看起来非常简单.任何影响用户声誉的事件(upvotes,downvotes,answer-accepted等)都会调用一种方法来审核用户的新声誉,并可能颁发徽章.

该系统听起来非常简单,但对于想要在未来几乎不费力地创建无数徽章的管理员而言,这看起来像是一个数据库 - 其中一些可能基于不同的标准,而不仅仅是用户声誉.

用户信誉可能是用户记录本身的值.但理想情况下,您不希望在创建新徽章时不必在用户表中添加新字段吗？例如"Edited 100 Entries"徽章 - 您不会在用户表中创建新列"entries_edited",不是吗？然后在每个条目编辑后增加...

任何提示？

Stackoverflow存档:

• 存储徽章标准的最佳方式 (不重复)
• 设计徽章系统:在哪里解雇业务逻辑？

注意:我不是问如何将徽章与用户关联起来.我不是问如何颁发徽章(将以编程方式完成)

我一直在考虑如何在新网站上实现类似于SO的徽章功能.存储徽章标准的最佳方法是什么？

两个想法:

• 所有代码
• '第二系统' - 创建用于定义徽章及其标准的元架构.将一些信息存储在数据库中,并让代码查询它以找出徽章及其标准.

还有更好的方法吗？

如何设计一个易于打开和关闭的可插拔点和徽章系统,以及易于变成自己的模块？

经过多次试验和错误后,我得出的结论是,点和徽章过于交织在应用程序的唯一业务逻辑中,它们无法以简单的方式外化(许多规则涉及理解应用程序的核心结构,这使得事物已经相当耦合)

我目前以简单的方式做所有事情 - 我在服务类的方法中外部化了所有业务逻辑(验证,持久性,游戏化,通知).然而,这些方法已经变得非常杂乱,我担心会很紧张.没有简单的方法来简单地关闭任何底层系统