背景:
某一天,老板突发奇想,想要做一款有趣又好玩的答题游戏,给你两天时间完成,但是希望你能理解公司因为疫情经营也不太景气,所以要求技术人员必须能够做到以最少的资源达到最好的性能,游戏是答题闯关游戏,选项呢是多选项,做好了,咱们就单车换摩托,做不好咱们就法制节目见,为了养家糊口,苦逼程序员就接下需求开干了
于是程序员开始提炼老板的需求要点:
①答案是多选项的
②要求节省资源
首先需要设计好多选项的存储模型,该如何设计呢,看看第二个要求,也没啥选择了,那就从压榨数据库上着手吧,既然节省资源,那就奔着以下两个要点来吧:
更小的通常更好
应该尽量使用可以正确存储数据的最小数据类型
。更小的数据类型通常更快, 因为它们占用更少的磁盘、 内存和
CPU缓存, 并且处理时需要的CPU周期也更少。
但是要确保没有低估需要存储的值的范围, 因为在schema中的
多个地方增加数据类型的范围是一个非常耗时和痛苦的操作。如果
无法确定哪个数据类型是最好的, 就选择你认为不会超过范围的最
小类型。最小的类型当然是tinyint了
简单就好
简单数据类型的操作通常需要更少的CPU周期。例如, 整型比
字符操作代价更低, 因为字符集和校对规则(排序规则) 使字符比
较比整型比较更复杂。ok,这里依然选择tinyint
实现:
类型选好了,那怎么表示多选项呢,能不能把多个选项用一个字段来存储呢?程序员灵机一动,想起来用位操作来表示多个选项,同时又能用一个字段来存储,哈哈 完美,达到了极尽所能的节省了资源,提高了性能。
可以把8个位包装到一个TINYINT 中, 按位操作来使用。在应用中为每个位定义名称常量来简化这个工作。
基于面向对象的设计思路抽象出两个数据模型:①题目 ②选项,于是进行了如下的表设计,
题目表:topic
序列 | 列名 | 类型 | 描述 |
1 | id | bigint(20) | 主键 |
6 | answer | tinyint(1) |
答案 |
15 | topic_desc |
varchar(100) | 题面文案 |
选项表:option
序列 | 列名 | 类型 | 描述 |
1 | id | bigint(20) | 主键 |
3 | number | tinyint(1) | 选项在二进制中的位置 |
6 | text | varchar(100) | 选项文案 |
来个例子:
题目:范冰冰哪里美?
选项:A.大长腿 B.小蛮腰 C.爷们性格
依据大众的审美观,答案当然是A和B了,那按照顺序,A在二级制倒序中的排位是第一位,B是第二位,用8位二进制标识是,00000011,换算成十进制就是3,所以存储的数据如下:
题目表数据:
id | answer | topic_desc |
1 | 3 | 范冰冰哪里美? |
选项表数据:
id | text |
1 | 大长腿 |
2 | 小蛮腰 |
3 | 爷们性格 |
至此,程序猿设计完了老板交代的游戏,并且交付,老板很满意,然而经营并非那么好,程序猿还是没能单车换摩托。
—————END—————
喜欢本文的朋友,关注 程序猿的十万个为什么,收看更多精彩内容
欢迎关注以上二维码,是对小猿最大的支持!