这是一个创建于 127 天前的主题,其中的信息可能已经有所发展或是发生改变。
看了下现在开源的 rbac 的用户权限系统 比如在指定部门下面新增一个用户,一般按照表结构设计,用户表 user 里面有 deptId 字段与 dept 部门表之间进行关联,但是这个字段就是一个普通的部门 id 字段,并没有设置外键与 dept 表进行关联.
所以在实际新增用户的时候,会业务层面新增用户的时候校验部门是否存在,如果存在才能新增用户:
流程如下:
(
业务 A: 新增用户, 新增用户需要确保用户所属部门存在
步骤 1: 根据 deptId 查询 dept 表中是否存在部门信息, 如果部门不存在,则抛出异常
步骤 2: 如果部门存在则新增用户到 user 表中, 用户新增成功.
)
(
业务 B: 删除部门, 删除部门的时候需要确保部门下不存在用户
步骤 1: 根据 deptId 查询 user 表, 如果指定部门下存在用户, 则提示不能删除部门
步骤 2: 如果部门下不存在用户, 则删除部门成功.
)
---------------
这两个业务 A 新增用户和 B 删除部门,如果执行有先后顺序,那么不会有问题?
如果存在业务 A 和业务 B 同时执行的可能(ps: 虽然说一般这种操作都是一个人去处理, 但是系统上并没有对这种情况进行限制, 那就是可能存在两个人, 一人执行业务 A 操作, 一人执行业务 B 操作)
那这样会不会导致这样一种结果:
执行业务 A 的步骤一之后,发现部门存在(后面可以在该部门下新增用户),但是这个时候业务 B 的步骤一也执行了,发现部门下确实没有用户(后面可以删除这个部门).
业务 A 的步骤一校验通过,业务 B 的步骤一也校验通过.
最后产生的结果就是新增了一条没有部门的异常用户数据.
这种异常情况流程应该如何处理呢?
比如 这种业务操作根本不存在? 还是 必须加锁限制业务 A 和业务 B 的操作必须顺序执行,还是说得加外键关联?
感觉这种情况设置外键也不起作用,我看了下表结构都是逻辑删除,这些逻辑删除的数据在数据库中还是存在的,就是业务系统中看不见了~~~
1 条回复 • 2025-05-16 10:32:55 +08:00
 |
|
1
concernedz 127 天前 1
我们 to B 很少考虑这个(几乎不存在),如果担心,可以加锁,其次同一业务步骤 1 和步骤 2 保证在一个事物就行
|