程序猿一次逆风翻盘的机会(第二期)

背景:

某一天,老板突发奇想,想要做一款有趣又好玩的答题游戏,给你两天时间完成,但是希望你能理解公司因为疫情经营也不太景气,所以要求技术人员必须能够做到以最少的资源达到最好的性能,游戏是答题闯关游戏,选项呢是多选项,做好了,咱们就单车换摩托,做不好咱们就法制节目见,为了养家糊口,苦逼程序员就接下需求开干了

 

于是程序员开始提炼老板的需求要点:

①答案是多选项的

②要求节省资源

 

首先需要设计好多选项的存储模型,该如何设计呢,看看第二个要求,也没啥选择了,那就从压榨数据库上着手吧,既然节省资源,那就奔着以下两个要点来吧:

 

更小的通常更好

应该尽量使用可以正确存储数据的最小数据类型

。更小的数据类型通常更快, 因为它们占用更少的磁盘、 内存和

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—————

 

 

喜欢本文的朋友,关注 程序猿的十万个为什么,收看更多精彩内容


 

程序猿一次逆风翻盘的机会(第二期)

程序猿一次逆风翻盘的机会(第二期)

欢迎关注以上二维码,是对小猿最大的支持!

上一篇:MySQL补充说明


下一篇:理解误区——mysql中tinyint与Java的数据类型的对应关系;tinyint(1) 与tinyint(4)的区别