[数据表字段设计思路争论]设计一个关于门禁路数通行次数字段的数据库设计

[xianbing278]

如题，关于门禁路数字段的设计有了分歧

需求（是一个整体需求，按段路说了）：

1.门禁是一个 lock_id ，它下面还有一路，二路，三路的通行权限。
2.现在有一个通行表里面保存了某个人在某个时间对于某个门禁的一个通行有效期，有这样一条记录在就相当于它有了一个临时通行卡这个作用。
3.每一次他点击按钮开门通行时会有一个通行记录，详细到某个门路上
4.现在需要对某个门禁的某个门路有一个通行次数的权限校验


解决方案：
第一个想法：
1.某个门路的通行次数做成一个配置项可动态调整，比如 1 路=>10 次，2 路=>3 次，3 路=>4 次。然后在需要校验的地方拿配置项内允许的通行次数和通行记录比较来判断权限


第二个想法：
1.某个门路的通行次数做成数据库字段，存入通行表内，比如 lock_one_validity_count,lock_two_validity_count,lock_three_validity_count 。分别代表三个门路的可通行次数，通行一次减一次的做法


请问哪种方式更合适呢

[codedreamstar]

看你的问题描述, 门禁卡, 门, 门禁策略, 通行记录这些概念对应的表是有的.

如果控制字段数量的话, 上个 JSON 字段得了, MySQL 8 (JSON 操作函数相对更丰富, 方便查询) 的话.

可以把有效期, 次数什么的都搞到这个 JSON 字段中, 因为这些都是相关设置, 极大概率会一起修改.

不能重构往往会导致简单的逻辑变得复杂且可维护性显著降低. 这种时候可以考虑实际情况看能不能硬气一下, 说服你的产品或者项目经理, 坚持你认为更优的方案.

当然如果之后不会变得更复杂, 直接使用你的第一个想法, 短平快.

[codedreamstar]

@ye4tar 我理解的他描述的应该是亮度 100-亮度 0, 延伸出亮度 50, 亮度 0-25-50 匀速变量. 换句话说就是对门是否开关延伸出各种控制开关的策略. 看起来不像是由 A 到 C 经过 B 这种, 按照现实逻辑一般也不需要控制开 B 门的前提是能开 A 门. 看 OP 怎么解释吧.

[xianbing278]

@ye4tar 是的，是个树形结构。”有没有存在一个目的地可以从 A 或 B 都可以进入“这个没太理解，举例说 1 门=>A,B,C 。2 门=>D,E,F 。现在是这样的

[xianbing278]

@codedreamstar ”看你的问题描述, 门禁卡, 门, 门禁策略, 通行记录这些概念对应的表是有的.“ 额其实门禁卡和门禁策略是没有的，现在麻烦的就是我想的是分开做，尽可能做成原子化，每个点都很清晰，但不让这么做，都做到一个表里面了。这个表内的一条记录就相当于是门禁卡，有效期和有效次数字段就是门禁卡的一个门禁策略。


”如果控制字段数量的话, 上个 JSON 字段得了, MySQL 8 (JSON 操作函数相对更丰富, 方便查询) 的话.

可以把有效期, 次数什么的都搞到这个 JSON 字段中, 因为这些都是相关设置, 极大概率会一起修改.“ 这个我们这边也很扯淡，用的 mysql 版本还是 5.6 ，有的同事不会用 mysql 的 json 操作，我是一点都不敢用 json

[LLaMA2]

@xianbing278

如果是树，就不存在我说的意外情况，
但是我还是和你确认下，我的举例是说 有 3 层门禁
前两层是 1 门 => ( A ,B, C) ，第三层是 A 可以到 DE B 可以到 FG ，C 可以到 DH ，此时第三次的目的地 D 可以从 A 过来，也可以从 C 过来，当然，标准的树是没有这种情况的


如果是树，
那么你使用闭合表记录路径关系
记录如下

1 1
1 A
1 B
1 C
1 D
1 E
A D
A E

此时我们就知道 1 是根节点，1 有直接子代 ABC ，1 有全部自带 ABCDE ，A 有直接子代 DE

接着你想授权的话 只需要记录目的地的是否可以访问，不需要记录外层门的是否可访问，

因为只要目的地的是否可刷门禁卡访问的开关是好的，那么外层门就一定可以访问，否则无法到达目的地，
当然，还需要考虑串门，以及恶意逗留的问题

总之，还需要大胆讨论，小心求证。

[cpstar]

一个字段两个字段不允许细化是个啥概念？如果是方案二，是不是每个人只有一条记录，往下减？那也就是说没有时间维度的最大 xx 次？那就减呗，减到 0 为之。然后需要再加一个用例，设置次数。于是用方案二的三个表， [人-次数] 关系，也行，费点劲——换句话说，其实还是我说的 [人-路-限制] 一个表拆成了三个表，每个表 [人-次数] 往下扣减。

[xianbing278]

@ye4tar 谢谢你的思路，和你讨论功能的实现方式是愉快的，唉

[xianbing278]

@cpstar 嗯嗯现在需求又变更了，以前的设计思路要更改了。谢谢你的发言建策