设计服务端数据表

课程表开发日志

1、服务器采用什么数据库？
现在主流的无非两种选择：SQL or NoSQL

SQL的话历史长，功能全面，稳定，资料多，肯定是首选。而NoSQL的数据库，不如Monodb，貌似比较适合那种纯API的服务端，对于我们这个项目，不能满足于此，故SQL是比较合适的选择。最后选择了比较熟悉的MySQL。

2、数据表如何设计？

第一种最直接的想法，完全按照用户端的功能来设计，只设计一个user表：

user : _id stunum password tel academy table mytable exam grade todo

其中：
table : 用户的课程表数据，以json存储
mytable : 用户自定义的课表（可能有自己添加的课程），以json存储。用户可以选择切换回table
exam : 考试信息，以json存储
grade : 成绩信息，以json存储
todo : 待办事项，以json存储

这样设计的话，可以说是很直白了，和客户端的功能无缝对接，但是明显感觉到有一种NoSQL的倾向（大量使用json），选择SQL的意义何在...

而且如此设计不便于对数据进行更细致地检索和利用，不够灵活。
比如要查找某学院成绩最高的人，要进行复杂的课程筛选就很难办到

那应该怎么做呢？对于我们感兴趣的数据，应该抽取出来做一个新的数据表，而不是包裹在json之中。

因此，增加一个Course表如下：
Course : _id name classroom weeks sections teacher hash

其中_id是自动生成的数值键，用于在表外引用course，然后还添加了一个hash字段，在添加课程的时候根据课程信息生成一个hash值（可能是类似于MD5之类的算法），用于防止添加重复的课程。

这样，user表中的table这个键就可以从复杂的json结构简化为一个只包含Course的id的列表。
在对课程进行复杂检索的时候（比如蹭课功能），就直接在Course表中检索，而不需处理User表。

再来讨论一个问题，我们真的需要将User表中的table值简化吗？如果简化为只包含Course的id的列表，那么要获取该用户的课表，就要做两次sql查询，而这本来是不必要的，如果我们一开始保存Course的时候就把信息留在table里，就只需要做一次检索。这样是在以空间来换时间，但以User表的体量来看（最大不超过20K），是可以接受的。前提是Course表的项在添加之后不会发生变化，这也是肯定地。

同理，可以增加一个exam表和grade表：

exam : _id name room time hash
grade : _id course_id user_id score

还有个问题，不知道SQL对于跨表查询的支持是怎样的。比如说，是否可以根据grade表查出某个学院的所有成绩，或某个学科的所有成绩？

经过这些分析，最后我得出一个结论：当我们的需求越来越复杂的时候，对数据表的要求也越来越高，最终数据表会发展到和源数据表趋同，最后达到一种模拟源数据表的效果，也就无所不能了吧。。