数据库表

• 这里只简单介绍数据库表结构，详情参见数据库文件
• 数据库中未建立索引，后期有需要的时候再建

知识相关

知识列表-list

key	备注	类型	长度
id	知识序号，主键，自增	int	11
title	知识标题	varchar	255
category	知识类别	tinyint	255
parent_id	上一级知识序号	int	11
video_id	视频文件序号	int	11
img_id	图片文件序号	int	11

知识列表是多级的，这样的需求有两种实现方式：

1. 每一级知识都有自己的表，这样的缺点是表数量会很多，优点是层级关系很清楚
2. 所有知识放在一个表中，这样的优点是只用一张表，后期如果做搜索查询之类的会少写不少表名，而且扩展性更强，如果要新增一个层级的时候，不需要建新表；缺点是层级关系不直观

考虑到我们的列表层级是不固定的，所以采用第二种方式

图片文件-file_image

key	备注	类型	长度
id	序号，主键，自增	int	11
name	文件名，带后缀	text	0

视频文件-file_video

key	备注	类型	长度
id	序号，主键，自增	int	11
name	文件名，带后缀	text	0

测试相关

在设计的时候需要考虑到几方面的因素，包括：

1. 可扩展性：各测试题目选项的数量是不固定的、正确答案是多选的
2. 可统计性：每道题目答题的统计情况：多少人答题、每个人的答题正确率、每个题目有多少人答过、每个测试题的答题正确率、错误选项出现的数量...

这里要注意测试题和选项是一对多的关系，最好将从属关系保存在“多”的一侧，便于扩展和统计。最后决定用三张表来做

测试类型表-test_category

key	备注	类型	长度
id	序号	int	11
name	类型名称	varchar	255
content	类型简介	varchar	255

测试题目表-test_question

key	备注	类型	长度
id	测试题编号	int	11
content	测试题题目文本	varchar	255
category_id	测试类型id	int	11

测试题目选项表-test_option

key	备注	类型	长度
id	选项编号	int	11
content	选项文本	varchar	255
question_id	选项所属的测试题编号	int	11
is_answer	选项是不是该测试题的正确答案	tinyint	1

测试结果表-test_result

key	备注	类型	长度
id	答题结果编号	int	11
uid	用户编号	int	11
question_id	答题结果所属的测试题编号	int	11
answer_id	选项编号	int	varchar	255
create_time	答案提交时间戳	datetime	0

这里要注意一个细节，测试题和测试题答案中的选项也是一对多的关系，所以在test_result表中，使用"question_id"区分所属的测试题；

使用"create_time"来区分用户的测试记录，每次测试无论有多少道题目，同一次测试的create_time字段都一样，这样在查询的时候，可以先使用"GROUP BY create_time"来得到测试记录数量，再遍历测试记录，根据每次测试的create_time信息查询该测试的详细数据。

例如一次测试题目数量为n，那么在提交测试结果时，test_result表会插入n条数据，每道题目插入一条数据，用一个字段(answer_id)保存答题者的选项(逗号分隔)，这样在业务层面不会由于数据库读写次数过多而影响API响应速度，至于统计的功能可以新建一张专门用于数据分析的表，使用类似test_result表的结构，在半夜访问量少的时候，从test_result表中导入分析表。

测试结果分析表-test_result_analysis

key	备注	类型	长度
id	答题结果编号	int	11
uid	用户编号	int	11
question_id	答题结果所属的测试题编号	int	11
answer_id	选项编号	int	11
create_time	答案提交时间戳	datetime	0

使用"create_time"来区分答题结果，比如某个题目用户选择了3个选项，那么就会插入三条记录到test_result表中，三条记录的question_id、create_time都一样。虽然这样设计数据冗余，并且写数据库的次数增加会导致响应速度下降，但是更便于统计