GeruzoniAnsasu
2023-05-07 23:12:34 +08:00
虽然这么说有点不太尊重,先道个歉…… 但我每次看到这种无法把需求抽象成概括性问题的帖总会觉得,这人想不出做法是一点也不冤。
首先要考虑的问题:这些数据谁来处理?可计算吗?向量维度是可变的吗
--------
比如你提的第一个需求,假设(反正你没说清)这种数字区间是用来做判断的,比如系统有个功能叫「设定标准」,标准=一组区间。那么是否存在 「判断(判断即计算,因为必然存在算数过程)给定输入是否符合已定义的标准」 的功能?如果有,是你负责的部分要进行这个判断,还是你只是在做数据持久化的中间件,你只关心数据的序列化形式不关心它的解析?向量维度的意思是,一个「标准」是否固定地只有上下界两个参数,还是有一个复杂的关联,包含了一系列数字区间?
如果一个条目里(或者你打算设计的表,一行中)只存在唯一一个区间,那显然只需要两个代表上下界的数字和两个代表开闭区间的逻辑符号即可,简单地 4 个列就能完成需求。或者更学究一点可以用 mask 数字来代表逻辑符号。
但如果「标准」这个条目和「区间数量」的关系是不确定的,一个条目中能关联任意多个不同区间,那显然不可能只用一张表实现。视乎具体需求的复杂度,可能需要
- 表 A ,保存「标准」的 id
- 表 B ,保存定义「标准」时可用的项目枚举,如「层高」=1 、「面积」=2
- 表 C ,保存「标准」包含的条目关系,如 [标准 id,项目枚举 id, 逻辑符号, 数字],[1,1,>,2.5],[1,1,<=,4],[1,2,>,10]
上述例子就表示 id=1 的「标准」包含 ( 2.5<层高<=4 且 面积>10 )两组区间
当然了,如果系统中不存在判断「是否符合标准 1 」的场景,那上述这些设计并不是必要的,甚至于假如处理数据的主体并不直接与数据库交互,它接收的是某种中间表示,那完全可以直接把它的结构化表示作为字符串存进数据库里,如 json {id:1, name:"标准 1", rules:[{"层高":[">2.5","<=4"]},{"面积":[">10"]}]}
--------
第二个要考虑的问题: 你真的是想「保存单选类型的数据」?
单说这个抽象后的问题「如何把 options 存进数据库」,那任何但凡有程序思维(他不用会写)的人都能想到用枚举表示 options ,然后把枚举值存起来即可,最多再额外存一下枚举值和字面表示的对应(如果不在代码里写死的话)。如果你遇到的是类似「如何保存非预定义(可任意新建和自定义)的枚举」的问题。那么这个答案是「字典表」。如果不是,那么你的第二条说明就不仅没能概括问题,还表述了完全错误的方向
还有第三个问题: 为什么要把区间和 option 枚举两个看不出逻辑关系的东西,糅合进同一个表里?在你的问题里并没有体现仅用一个表来同时完成两个需求的必要性。如果有,那能不能解释一下这个表的 primary key 是什么? 为什么上述两个「配置」都会与这个 key 唯一对应?
p.s.题外话,突然发现软件工程那些没人在意的 UML 建模什么的,或许还真的对某些特定场景有帮助,比如当你想不出业务里的对象关系时