我对我试图解决的问题有一个可能的解决方案，但为了安全起见，我想在这里运行它。面临的挑战是确保在考试应用程序中完成某些测试问题的用户在后续测试中不会再次遇到这些问题。
我没有使用 SQL 数据库，它允许我使用左连接、子查询、临时表等。我正在使用 Google App Engine 的数据存储区，并希望在单个 HTTP 请求和单个线程中（最好在一秒内）获取所需的信息。
假设有 100,000 个特定类型（例如同义词）的词汇问题。该应用程序将从题库中选择 30 个问题用于考试的给定部分。这就是我想做的事情：
- 当第一次创建问题时，为其分配池中的随机整数位置。
- 在个人第一次考试时，选择一个随机数字，然后选择前 100 个问题，按位置排序，位置大于该数字。跟踪数字作为问题窗口的下限，以及整个池子的起始位置。跟踪结果集中最后一个问题的（最大）位置作为新窗口的上限。
- 从窗口中随机选择 30 个问题，然后将它们作为部分。存储剩余的 70 个问题以供稍后考试以及可能的后续考试使用。
- 当用户浏览其他部分（例如，用于练习），并且当前窗口中的剩余问题列表已耗尽时，请从池中选择接下来 100 个位置大于先前存储的上限的问题。将旧的上限作为新的下限，并找到新窗口的上限。
- 当查询返回的问题少于 100 个问题时，回绕到 0 的位置并继续，直到遇到原始起点（不太可能有人会遍历整个池，但确定这一点很重要）。
随机分配职位的主要原因是为了抵消问题编写风格变化的影响，例如，较早的问题在经验较少时写的问题与后来的问题相比。
应用程序会为问题分配一个位置，而不检查该位置是否唯一。如果问题数量足够多，生日悖论 http://en.wikipedia.org/wiki/Birthday_paradox表明重复职位将变得越来越普遍。我的想法是，偶尔出现重复不会有什么坏处，而且这会让事情变得比确保给定位置是唯一的更简单，这可能需要重试以及随之而来的相关网络成本。没有重复的问题比确保向用户显示一系列问题中的每个问题更重要。
有一个更好的方法吗？不用担心重复职位可以吗？
使用 0 到 1 之间的浮点数而不是整数。它有一个很好的域，不会随着实体数量的变化而改变，并且双精度数有一个 52 位尾数，在我们可以预期发生碰撞之前，它为我们提供了大约 2^26 个对象；远远超过你正在处理的事情。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
