PS:这是一个以前遇到的设计问题，在这里记录一下思考过程
设计目标：
- 有一个单词本，全集在10000个以下
- 用户背单词时，每个单词都有一个背诵状态(第一次、第二次…)，状态在10个以内
- 单词的字符都是英文字符，在ASCII范围内，字符数在20个以内
- 有很多用户，想要把背单词情况从客户端同步到服务器上，以便不同设备间共享
- 将背单词情况尽量压缩，以便网络同步
可能的方案：
方案1：
- 在服务端，设立一个单词表(单词id，单词音标，单词文字，单词解释，单词读音文件…)
- 在服务端，设立一个关联表，记录每个用户的背单词情况（关联id，单词id，用户id，进度状态…）
- 在服务端，设立一个同步状况记录（id，用户id，同步时间，hash码…）
- 每次用户同步时，需要把所有单词id及对应的单词状态提交，然后在服务端统一更新，如果判断时间更旧则客户端下载。
方案2：
- 在服务端设立单词表…
- 在服务端，设立一个关联表，其中的blob字段直接记录所有单词进度(id,用户id,同步时间，hash码，blob存储…)
- 用户同步时，根据同步时间及hash码，判别是提交还是下载
- blob存储格式：每个单词及状态用一个int表示，其中低地址的short型存储单词id、高地址的short型存储单词状态
性能比较：
在通信时，为了确保逻辑简单，每次都要将所有单词及状态进行传输。
如果是方案1，单词id和状态分别(按int)发送，容量要翻一倍。及时传输时进行压缩，在服务端涉及到更新的内容也较多。
方案2，已经对信息进行了最大压缩，传输、存储容量都较小、IO次数也少。
单词全集10000，需要位数为14位；单词状态10个，需要的位数为4位。加起来需要18位存储，加上未来的一些扩展性，32位的int型正好放的下。