1
ChuanlongYou 344 天前 via Android
方法二的话,会存在比 4 路更多路数的控制器吗?
|
2
xianbing278 OP @ChuanlongYou 会,可能存在这种情况的
|
3
ChuanlongYou 344 天前 via Android
@xianbing278 虽然字段省事,用就是每条记录都得按照最大路数的结构存,个人感觉不是太好。我之前做的门禁系是存路为实体,和控制器是绑定关系。
|
4
28Sv0ngQfIE7Yloe 344 天前
如果周期结束通行次数会重置的话,放表里会比较麻烦。扔到 Redis 做吧
|
5
xianbing278 OP @ChuanlongYou "我之前做的门禁系是存路为实体,和控制器是绑定关系"不好意思,这句话没理解,能解释下是什么意思吗
|
6
xianbing278 OP @Morii 会的,还有重置相关的一个规则控制。扔到 redis 做是什么样做呢
|
7
ChuanlongYou 344 天前 via Android
@xianbing278 就是表设计上是把控制器和路数拆开了。把每个门路对应着下挂的“门”,“门”去绑定控制器,做操作业务是对应着“门”,不是对“控制器”。之前这样考虑到像一个 2 路控制器,也会存在只用其中一路的情况。
|
8
xianbing278 OP @ChuanlongYou 噢大概明白意思了,就是一路对应一路的控制器,二路对应二路的控制器,包括数据表,每个门对应的门路也都是以字母表形式存在。是这样吗
|
9
ChuanlongYou 344 天前 via Android
@xianbing278 可能是吧。就是把“路”给当成一个实体来做。按照我说的思路,通行记录不和控制器产生直接关系,和门有关系,用字段 door_id , 如果需要查控制器就通过 door_id 去查属于哪个控制器的 ,把路数当“门”好理解些,这是种思路。还是得按照你们的主表设计来考虑吧。
|
10
ChuanlongYou 344 天前 via Android
@xianbing278 我刚刚看了有点类似,你提供的第一种方案。
|
11
cpstar 344 天前
安装传统的关系设计,这不就是 [人(不知道有没有)-门禁(路)-限制] 的三者对应关系?一个表不就够了。然后通行记录做一个 log 表,至于超限,在 log 表里做统计,与第一个表的上限进行比对。
至于硬件控制器,肯定得需要三个,分别对应三路。 |
12
LLaMA2 344 天前
简单点问下:
你所说的一路,二路,三路是不是又是一层门 即,你的门禁嵌套是不是和常见的组织架构一样, 即,总公司(大门) ==> 分公司(一路,二路,三路) 。。。。。 依次类推 如果是,那么就有更简单的办法。 求证! |
13
nice2cu 344 天前
类似银行的 账户余额 和 账户流水? 感觉都行的吧 数据量少 方案 1 就行 count 不影响效率。 方案二 对于部准确时 得有矫正措施
|
14
codedreamstar 343 天前
第一个想法就行, 只不过通行次数别拿记录来对比, 直接加这么个状态做.
实体 门禁卡, 门, 门禁策略, 通行记录. 用例 新增门禁卡: 添加一个门禁卡 新增门: 添加一个门 授权: 授权门禁卡相关门的门禁策略 鉴权: 检测门禁卡进入门的门禁策略评估并记录 重点说一下门禁策略, 就是简单的门禁卡和门的关联以及有效期和最多通行次数以及已通行次数, 如果需要周期刷次数就加一个次数刷新时间, 评估的时候根据刷新时间置 0 一下就行. 需要更深度更复杂的扩展可以再讨论. |
15
yuyuf 343 天前
选第一种,扩展性好。
第二种,随便加点功能都没法用 |
16
xianbing278 OP @cpstar 嗯嗯明白你的思路,一个表里面存入人对门禁路数的最大限制次数,然后使用 log 表的统计对比来实现判断。我也觉得这种方式比较好,但是他妈的不让做细化
|
17
xianbing278 OP @ye4tar 不是的,我拿台灯举例吧。台灯首先有开,关两个最基本操作。然后在之上再延伸出 A 模式,B 模式,C 模式这三种模式。目前要对他能使用的模式次数做限制
|
18
xianbing278 OP @nice2cu 嗯嗯
|
19
xianbing278 OP @codedreamstar 多谢大哥这么明确的思路。现在是不允许往细化方向做,就只允许一个字段两个字段来的去控制,所以也是有些无奈
|
20
LLaMA2 343 天前
|
21
codedreamstar 343 天前
看你的问题描述, 门禁卡, 门, 门禁策略, 通行记录这些概念对应的表是有的.
如果控制字段数量的话, 上个 JSON 字段得了, MySQL 8 (JSON 操作函数相对更丰富, 方便查询) 的话. 可以把有效期, 次数什么的都搞到这个 JSON 字段中, 因为这些都是相关设置, 极大概率会一起修改. 不能重构往往会导致简单的逻辑变得复杂且可维护性显著降低. 这种时候可以考虑实际情况看能不能硬气一下, 说服你的产品或者项目经理, 坚持你认为更优的方案. 当然如果之后不会变得更复杂, 直接使用你的第一个想法, 短平快. |
22
codedreamstar 343 天前
@ye4tar 我理解的他描述的应该是亮度 100-亮度 0, 延伸出亮度 50, 亮度 0-25-50 匀速变量. 换句话说就是对门是否开关延伸出各种控制开关的策略. 看起来不像是由 A 到 C 经过 B 这种, 按照现实逻辑一般也不需要控制开 B 门的前提是能开 A 门. 看 OP 怎么解释吧.
|
23
xianbing278 OP @ye4tar 是的,是个树形结构。”有没有存在一个目的地可以从 A 或 B 都可以进入“这个没太理解,举例说 1 门=>A,B,C 。2 门=>D,E,F 。现在是这样的
|
24
xianbing278 OP @codedreamstar ”看你的问题描述, 门禁卡, 门, 门禁策略, 通行记录这些概念对应的表是有的.“ 额其实门禁卡和门禁策略是没有的,现在麻烦的就是我想的是分开做,尽可能做成原子化,每个点都很清晰,但不让这么做,都做到一个表里面了。这个表内的一条记录就相当于是门禁卡,有效期和有效次数字段就是门禁卡的一个门禁策略。
”如果控制字段数量的话, 上个 JSON 字段得了, MySQL 8 (JSON 操作函数相对更丰富, 方便查询) 的话. 可以把有效期, 次数什么的都搞到这个 JSON 字段中, 因为这些都是相关设置, 极大概率会一起修改.“ 这个我们这边也很扯淡,用的 mysql 版本还是 5.6 ,有的同事不会用 mysql 的 json 操作,我是一点都不敢用 json |
25
LLaMA2 343 天前
@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 接着你想授权的话 只需要记录目的地的是否可以访问,不需要记录外层门的是否可访问, 因为只要目的地的是否可刷门禁卡访问的开关是好的,那么外层门就一定可以访问,否则无法到达目的地, 当然,还需要考虑串门,以及恶意逗留的问题 总之,还需要大胆讨论,小心求证。 |
26
cpstar 343 天前
一个字段两个字段不允许细化是个啥概念?如果是方案二,是不是每个人只有一条记录,往下减?那也就是说没有时间维度的最大 xx 次?那就减呗,减到 0 为之。然后需要再加一个用例,设置次数。于是用方案二的三个表, [人-次数] 关系,也行,费点劲——换句话说,其实还是我说的 [人-路-限制] 一个表拆成了三个表,每个表 [人-次数] 往下扣减。
|
27
xianbing278 OP @ye4tar 谢谢你的思路,和你讨论功能的实现方式是愉快的,唉
|
28
xianbing278 OP @cpstar 嗯嗯现在需求又变更了,以前的设计思路要更改了。谢谢你的发言建策
|