我正在实施一个网站，我的用户将在完成某些目标或任务后获得徽章。
徽章也会有等级/颜色。因此，例如，用户将从 0 级青铜徽章开始，随着他们的进步，他们将获得 1 级青铜徽章，然后再经过几个级别，他们将获得 0 级银徽章，依此类推。
我正在构建数据库，但不确定如何将徽章连接到用户。
我想出的想法是为用户创建 1 个表，为徽章创建 1 个表，以及第三个将 UserID 连接到 BadgeID：
我关心的是优化。随着更多用户加入网站并获得徽章，访问表和搜索记录不会变慢吗？
我在这里阅读了有关使用 Java 中的单例在服务器上定期运行脚本并根据规则检查用户状态以升级满足更高目标的徽章的信息。这种方法真的可扩展吗？还是我应该关注这篇文章？
TIA
随着更多用户加入网站并获得徽章，访问表和搜索记录不会变慢吗？
如果您的表被正确索引，则并不重要。
想一想……如果百科全书有五倍的文章，你会不会花很长时间才能在百科全书中找到一篇文章？
并不真地; 因为百科全书是按字母顺序索引的，所以即使文章数量显着增加，也不会花费太多时间来查找内容。但是，如果它没有被编入索引，那么随着百科全书规模的扩大，查找内容所需的时间将成倍增加。
鉴于您的问题和您链接的资源，我觉得您只关注“徽章”，可能会导致您错过更普遍的情况。
例如，如果徽章总是按顺序发放，您只需要记录某人最后获得的徽章；在这种情况下，他们一定已经获得了最后一个徽章之前的所有徽章。如果它们不是增量的，则使用您描述的链接表可能会更好。
尝试用与数据库或数据建模相关的术语来描述您的问题，而不是专门与您的问题领域相关的术语（“徽章”）。这应该可以帮助您弄清楚您应该寻找什么样的信息，并最终引导您采取正确的行动。
现在，您可以实现它，就像您描述的那样（1 个徽章表、1 个用户表、1 个关系表）。
GGG 只存储最后一个徽章的做法非常好，因为一个用户只能拥有一个徽章，并且徽章是按顺序发放的。但是，您不需要关系表。
使用关系表，您可以同时向用户分配多个徽章（1:n 关系），例如 Foursquare 徽章。
如果你使用 MySQL，你应该使用 InnoDB。
如果您遇到性能问题，您可以考虑在存储前使用某种缓存层，例如 memcached 或仅使用 NoSQL DB 来存储徽章信息。但是当你不得不面对这些问题时，我会担心这些问题。