-1

我正在构建一个“发现差异”的多人游戏。

游戏规格如下:

  1. 每场比赛最多可以有10名玩家。
  2. 用户不能两次看到同一张图片。
    (一张图片由四张图片组成,用户必须“找出它们之间的区别”)

我收集了数千甚至可能是数万张图片可供选择。我面临的问题是一种极其低效且不可扩展的方法,用于查找尚未有游戏玩家看过的图片。

在我的数据库中,我有usage table以下字段:

  1. 图片ID
  2. 用户身份

我目前的解决方案如下:

用户进入游戏,应用程序从数据库中选择一张未出现在该用户使用表中的图片,并且对于进入的每个用户,我运行相同的功能,仅添加同一游戏中其他用户已经看过的图片的值。

我担心一旦有数万张图片的数据库可供选择,并且使用表已经被以前的游戏填满,该功能只会花费太长时间而破坏游戏的流程。

这种方法的可扩展性不是很好,我期待相当稳定的流量,这意味着正在玩很多游戏。


有没有人对如何改进这个逻辑或更好的数据库结构有任何建议?

4

3 回答 3

4

您可以简单地向图片表(不是用户/图片映射)添加一个字段,用于标记图片是否已被使用。然后,您可以在使用图片时设置该标志,并索引该字段以快速识别未使用的图片。这有效地将结果缓存到 hasBeenUsed() 函数。

有些人可能会反对各种理由,并且这种过早的优化会导致高度混乱且耦合非常紧密的结构。惩罚未来的可维护性。

另一种方法是将每张图片都放在用户/图片映射表中。如果不使用图片,则其关联的 user_id 保留为 NULL。一个带有picture_id 的索引将很快识别未使用的图片。

But most of all, it actually depends on the query you have to make this random selection. Very often (but not always) poorly scalable algorithms can be replaced with much more scalable algorithms without changing the database structure at all. But to know that we need to see your query, as well as the schema and behavioral information about the data (constraints, likely %unused, etc).

于 2011-12-15T13:42:36.830 回答
3

我认为这是过早的优化。

虽然“数以万计”对一个人来说听起来很多,但对于 SQL 引擎来说几乎没有。一些实现甚至不会在 50-60k 行以下的表上使用索引,因为将整个内容加载到内存中会更快。

我建议EXISTS在大多数实现中使用哪些短路来编写查询,并且应该足够快以满足您的目的。

如果您为您的表结构和/或一些示例数据发布一些示例代码,我们可能可以协助查询,但我认为您什么都不担心。

于 2011-12-15T13:22:36.270 回答
0

10 个用户对 10,000 张图片 - 使用概率论,您需要在检查这 11 张图片后选择 11 张图片(我建议使用一些随机方法)以找到第一个唯一的。

于 2011-12-15T13:20:42.153 回答