本文主要是介绍程序猿一次逆风翻盘的机会（第二期），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
背景：
某一天，老板突发奇想，想要做一款有趣又好玩的答题游戏，给你两天时间完成，但是希望你能理解公司因为疫情经营也不太景气，所以要求技术人员必须能够做到以最少的资源达到最好的性能，游戏是答题闯关游戏，选项呢是多选项，做好了，咱们就单车换摩托，做不好咱们就法制节目见，为了养家糊口，苦逼程序员就接下需求开干了
于是程序员开始提炼老板的需求要点：
①答案是多选项的
②要求节省资源
首先需要设计好多选项的存储模型，该如何设计呢，看看第二个要求，也没啥选择了，那就从压榨数据库上着手吧，既然节省资源，那就奔着以下两个要点来吧：
更小的通常更好
应该尽量使用可以正确存储数据的最小数据类型
。更小的数据类型通常更快， 因为它们占用更少的磁盘、 内存和
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—————
喜欢本文的朋友，关注 程序猿的十万个为什么，收看更多精彩内容
欢迎关注以上二维码，是对小猿最大的支持！
这篇关于程序猿一次逆风翻盘的机会（第二期）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
