dream4ever 最近的时间轴更新
dream4ever's repos on GitHub
39 人关注
Chinese-Errata-for-JavaScript-The-Definitive-Guide
《JavaScript权威指南(第六版)》勘误表中文版
27 人关注
blog-articles
on the road
24 人关注
Knowledge-Base
record every requirement and solution here
12 人关注
Coding-Life
Collection of notes and resources related to coding~
HTML · 0 人关注
blog
HTML · 0 人关注
dream4ever.github.io
CSS · 0 人关注
hugo-theme-zozo
:star2: A simple and beautiful theme for Hugo
0 人关注
MS-Office
Office Operation Note
Vue · 0 人关注
NFT-Parser-0x01
编号为0x01的 NFT Parser,渲染 NFT +
0 人关注
Pics
Store all the images used in articles
JavaScript · 0 人关注
puppeteer-scripts
dream4ever

dream4ever

V2EX 第 140551 号会员,加入于 2015-09-29 12:04:25 +08:00
今日活跃度排名 5096
MongoDB 按题型保持一定比例抽题
MongoDB  •  dream4ever  •  37 天前  •  最后回复来自 dream4ever
12
感觉进入了职业倦怠期
程序员  •  dream4ever  •  57 天前  •  最后回复来自 normanzhxu
20
如何为游戏排行榜设计对应的数据库
数据库  •  dream4ever  •  122 天前  •  最后回复来自 bsg1992
11
无限抽题功能的实现思路
问与答  •  dream4ever  •  140 天前  •  最后回复来自 dream4ever
6
阿里云服务器云盘备份至本地的可行方案
服务器  •  dream4ever  •  246 天前  •  最后回复来自 Aliencn
1
业务迁移方案讨论
Web Dev  •  dream4ever  •  143 天前  •  最后回复来自 dream4ever
36
PDF 试卷资源管理方案设计
Web Dev  •  dream4ever  •  256 天前  •  最后回复来自 baobao1270
3
想买个游戏本玩游戏 + Web 开发
硬件  •  dream4ever  •  247 天前  •  最后回复来自 Aria2Hank
9
dream4ever 最近回复了
真遇到重大事故又找不着头绪的时候,心里就完全不是这种感觉了……
13 天前
回复了 IvanLi127 创建的主题 React React 生态里的 umi.js,很好用吗?
@noe132 这代码看着 真舒服,好评。
@sagaxu 我一同事负责的一项业务有不少 SQL 查询,前一段时间发现服务器 CPU 经常飙到 100%,排查来排查去发现一堆慢查询,最后追根溯源发现数据库各个表所有被查询到的字段都没有设置索引……
@wh469012917 他们这个智商,就告别这一行吧
37 天前
回复了 dream4ever 创建的主题 MongoDB MongoDB 按题型保持一定比例抽题
@no1xsyzy 小黄鸭调试法很久以前就看到过,不过一直都没有很好地践行这个方法,工作好几年了,感觉工作的方法和习惯还是很原始 @_@
37 天前
回复了 dream4ever 创建的主题 MongoDB MongoDB 按题型保持一定比例抽题
@xuanbg
@no1xsyzy

我这几天又思考了一下这个随机抽题的需求和实现思路,整理后的内容如下,欢迎指正:

前提:
1. 题库中一共有 N 道题。目前这个 N 为四位数,且在可以预期的未来,也不会有大量的增长。
2. 每道题目均为单选题、多选题、判断题中的一种。
3. 单选题、多选题、判断题的数量之比为 N1 : N2 : N3,且 N1 + N2 + N3 = N 。

需求:
1. 对每个用户来说,在每一轮游戏中,系统会将题库中的这 N 道题目,最多只有一次地、随机地呈现给用户,让用户回答。
2. 如果用户答对了题库中的所有题目,或者答错了 1 道题,则本轮游戏结束。
3. 为减轻系统负担,对于题库中的 N 道题,每次从中抽取 M 道题,全部抽完假设共需 L 次。对于每次抽取到的 M 道题,单选题、多选题、判断题的比例,尽量保持在 N1 : N2 : N3 这个比例上,也就是和这三类题目在总题库中的比例尽量相同。
4. 对同一个用户而言,各轮游戏的题目出现顺序应当不同,比如某一轮最开始拿到的题目是 1 、5 、9 、7,下一轮就不能也是这个顺序了。对于不同用户则没有要求。

大致实现思路:
1. 由于题目数量不多,可以在数据库中给题目增加一个序号字段,用自增的正整数来标记每一道题目的序号。
2. 在每个用户的每一轮游戏开始前,将所有题目的序号按题目类型进行分组,发给用户。例如用户收到的数组是
arr = [[1, 5, 7, 10, ...], [2, 3, 4, 8, ...], [6, 9, 11, 13, ...]],那么 arr[0]、arr[1] 、arr[2] 分别是所有单选题、多选题、判断题的序号。
3. 由于在一轮游戏中,每一次需要抽取 M 道题目,那么可知需要抽取单选题的数量为 Q1 = M * N1 / N,多选题为 Q2 = M * N2 / N,判断题为 Q3 = M * N3 / N 。
4. 前端在 arr[0] 中随机抽取 Q1 个元素为单选题的序号,在 arr[1] 中随机抽取 Q2 个元素为多选题的序号,在 arr[2] 中随机抽取 Q3 个为判断题的序号,并将这三组序号分别从 arr[0]、arr[1]、arr[2] 中移除。
5. 前端用这三组序号,从后端抽取 Q1 + Q2 + Q3 共 M 道题目并呈现给用户,让用户答题。
6. 如果这 M 道题用户全部回答正确,则重复第 4 、5 两步,继续抽取新的 M 道题给用户,直到用户答对所有题目,或者答错 1 道题目。

上面这个思路把抽题功能的主要部分交给了前端来做,感觉这样后端的负担可以小一些,也是对后端不够熟悉,就选择了这么一个相对比较取巧的办法。

PS:在整理这个需求和实现思路的时候,发现自己的表述的确不够清晰准确,就上面这段文字,来来回回修改了好几遍,用了两个多小时才完成,就这还是感觉表达得不够好,知易行难呐。
@yoa1q7y
@code4you
看了看 typeorm,prisma,sequelize,这三个 repo 的 issues 都是 1200+、1300+,哈哈
@Smash GitHub 的搜索结果默认是按照“Best match”排序的,你切换成按照“Most stars”排序,typeorm 就排第一了。
@fox0001

1. 光盘里放的是执行程序,不审查源代码,只审查最终产品。
2. 这一点倒是没有要求,这么说的确弄个一键部署方便很多。
3. 只是审查用,并不是长期运行,所以这些怎么方便怎么来。
@ksc010 对,需要实现的就是你这样的效果,我去研究一下。
关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3843 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 22ms · UTC 02:24 · PVG 10:24 · LAX 19:24 · JFK 22:24
♥ Do have faith in what you're doing.