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

[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 。分别代表三个门路的可通行次数，通行一次减一次的做法


请问哪种方式更合适呢

[ChuanlongYou]

方法二的话，会存在比 4 路更多路数的控制器吗？

[xianbing278]

@ChuanlongYou 会，可能存在这种情况的

[ChuanlongYou]

@xianbing278 虽然字段省事，用就是每条记录都得按照最大路数的结构存，个人感觉不是太好。我之前做的门禁系是存路为实体，和控制器是绑定关系。

[Morii]

如果周期结束通行次数会重置的话，放表里会比较麻烦。扔到 Redis 做吧

[xianbing278]

@ChuanlongYou "我之前做的门禁系是存路为实体，和控制器是绑定关系"不好意思，这句话没理解，能解释下是什么意思吗

[xianbing278]

@Morii 会的，还有重置相关的一个规则控制。扔到 redis 做是什么样做呢

[ChuanlongYou]

@xianbing278 就是表设计上是把控制器和路数拆开了。把每个门路对应着下挂的“门”，“门”去绑定控制器，做操作业务是对应着“门”，不是对“控制器”。之前这样考虑到像一个 2 路控制器，也会存在只用其中一路的情况。

[xianbing278]

@ChuanlongYou 噢大概明白意思了，就是一路对应一路的控制器，二路对应二路的控制器，包括数据表，每个门对应的门路也都是以字母表形式存在。是这样吗

[ChuanlongYou]

@xianbing278 可能是吧。就是把“路”给当成一个实体来做。按照我说的思路，通行记录不和控制器产生直接关系，和门有关系，用字段 door_id ， 如果需要查控制器就通过 door_id 去查属于哪个控制器的 ，把路数当“门”好理解些，这是种思路。还是得按照你们的主表设计来考虑吧。

[ChuanlongYou]

@xianbing278 我刚刚看了有点类似，你提供的第一种方案。

[cpstar]

安装传统的关系设计，这不就是 [人（不知道有没有）-门禁（路）-限制] 的三者对应关系？一个表不就够了。然后通行记录做一个 log 表，至于超限，在 log 表里做统计，与第一个表的上限进行比对。

至于硬件控制器，肯定得需要三个，分别对应三路。

[LLaMA2]

简单点问下：
你所说的一路，二路，三路是不是又是一层门

即，你的门禁嵌套是不是和常见的组织架构一样，
即，总公司（大门） ==> 分公司（一路，二路，三路） 。。。。。

依次类推

如果是，那么就有更简单的办法。

求证！

[nice2cu]

类似银行的 账户余额 和 账户流水？ 感觉都行的吧 数据量少 方案 1 就行 count 不影响效率。 方案二 对于部准确时 得有矫正措施

[codedreamstar]

第一个想法就行, 只不过通行次数别拿记录来对比, 直接加这么个状态做.

实体
门禁卡, 门, 门禁策略, 通行记录.

用例
新增门禁卡: 添加一个门禁卡
新增门: 添加一个门
授权: 授权门禁卡相关门的门禁策略
鉴权: 检测门禁卡进入门的门禁策略评估并记录

重点说一下门禁策略, 就是简单的门禁卡和门的关联以及有效期和最多通行次数以及已通行次数, 如果需要周期刷次数就加一个次数刷新时间, 评估的时候根据刷新时间置 0 一下就行.

需要更深度更复杂的扩展可以再讨论.

[yuyuf]

选第一种，扩展性好。
第二种，随便加点功能都没法用

[xianbing278]

@cpstar 嗯嗯明白你的思路，一个表里面存入人对门禁路数的最大限制次数，然后使用 log 表的统计对比来实现判断。我也觉得这种方式比较好，但是他妈的不让做细化

[xianbing278]

@ye4tar 不是的，我拿台灯举例吧。台灯首先有开，关两个最基本操作。然后在之上再延伸出 A 模式，B 模式，C 模式这三种模式。目前要对他能使用的模式次数做限制

[xianbing278]

@nice2cu 嗯嗯

[xianbing278]

@codedreamstar 多谢大哥这么明确的思路。现在是不允许往细化方向做，就只允许一个字段两个字段来的去控制，所以也是有些无奈

[LLaMA2]

@xianbing278 你说的不就是和我说的一样。

先打开才能后续选择 ABC 三者其一，通俗地说，即你的门禁是一个树形结构。

有没有存在一个目的地可以从 A 或 B 都可以进入

求证

[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 嗯嗯现在需求又变更了，以前的设计思路要更改了。谢谢你的发言建策