和人相关的一个很紧密的部分便是权限模块,这一块的数据库和功能组件设计完全能够独立出来讲,有人还专攻这个
不过为了保持一致,接着讨论权限表的设计。
权限表需要一个权限数据表来说明需要对那些系统的功能进行授权:
Module表
ModuleName | 字符 | 模块名 |
ModuleShowName | 字符 | 模块展示名 |
Id | 整型 | 数据id |
Status | 整型 | 数据状态 |
CreateTime | 长高精度日期 | 数据创建时间 |
CreateBy | 整型 | 创建人:人数据id |
ModifyTime | 长高精度日期 | 数据修改时间 |
ModifyBy | 整型 | 修改人:人数据id |
IsDelete | 布尔 | 数据是否逻辑删除 |
Function功能表
ModuleId | 整型 | 模块id,可以非必有数据 |
ParentId | 整型 | 父级功能id |
FunctionName | 字符 | 功能名 |
FunctionShowName | 字符 | 功能展示名 |
Id | 整型 | 数据id |
Status | 整型 | 数据状态 |
CreateTime | 长高精度日期 | 数据创建时间 |
CreateBy | 整型 | 创建人:人数据id |
ModifyTime | 长高精度日期 | 数据修改时间 |
ModifyBy | 整型 | 修改人:人数据id |
IsDelete | 布尔 | 数据是否逻辑删除 |
UserId | 整型 | 由于是系统使用概念,故和用户数据做关联而不是人的数据表 |
FunctionId | 整型 | 功能表id |
StartDate | 长精度日期 | 授权开始时间 |
EffectiveDate | 长精度日期 | 授权有效截止时间 |
Id | 整型 | 数据id |
Status | 整型 | 数据状态:需要暂停、停止、正常、未启用四种状态 |
CreateTime | 长高精度日期 | 数据创建时间 |
CreateBy | 整型 | 创建人:人数据id |
ModifyTime | 长高精度日期 | 数据修改时间 |
ModifyBy | 整型 | 修改人:人数据id |
IsDelete | 布尔 | 数据是否逻辑删除 |
此系列以技术积累一般(没有超级牛人)的组织为目标,数据量根本就不打算向阿里和企鹅的方向去想,设计目标够用就行,没成为GCC流传度软件那样的妄想。
所以,如果不是那种会害人产生经济损失或者技术上确实太丢人的bug,希望大家拿砖轻砸。
版权声明:本文为博主原创文章,未经博主允许不得转载。