一 系统管理设计
1菜单管理
菜单数据结构设计
0001系统管理
0001|0004 权限管理
0001|0005 菜单管理
0001|0004|0001 菜单权限
0001|0004|0002 操作权限
0001|0004|0003 数据权限
0001|0004|0004 跨权分配
0001|0004|0004|0001 数据控制
0001|0004|0004|0002 数据共享
2用户管理
3角色管理
4部门管理:
部门数据结构设计
0001总部
0001|0004 财务部
0001|0005 软件部
0001|0004|0001 社保组
0001|0004|0002 工资组
0001|0005|0001 杰信组
5权限管理
5.1菜单权限
指定某个人具有看到某些菜单的权限。基于角色权限,用户、角色、权限(URL、主菜单、左侧菜单)的访问控制。
5.2操作权限
指定某个人在看到某些菜单以后,能进行的某些操作与不能进行的某些操作。基于单个菜单页签中的按钮的控制。也就是控制用户的CRUD操作。
5.3数据权限
指定某个人能在某个菜单下进行CRUD的数据。纵向的数据权限过滤:对数据进行过滤。
1) 本人(专责):登录后只能看到自己的信息
Where条件 create_by = #{当前登录者id}
2) 部门(集团公司):登录后登录人是经理级别
A. 只能看本部门
Where条件create_dept=#{当前登录者所在的部门}
B. 看到所有下属的数据
Where条件create_dept like #{当前登录者所在部门id}%
C. 只能看到本部门和直属下属的数据
Where条件 create_dept=#{当前登录者所在的部门}
And create_dept like #{当前登录者所在部门}
5.4跨权分配
指定某个人能对某个人或者部门的的权限进行操作。
单独加表或者xml文件实现,这个表可以是权限配置表,某个人可以开到某个或某些菜单下的某种数据
5.4.1:数据控制
Where 条件 func_code=(权限配置表中的菜单编码集)and (节点下字段A=’ ’ and 字段B= ‘ ’ )
5.4.2:数据共享
共享某些部门与某些人的数据
Where条件create_dept in (当前登录者配置的管理的部门集合)
Or
Create_by in (当前登录者配置的管理的人员集合)
6日志管理:
6.1 操作日志
7 字典管理
7.1数据字典
它是一个通用结构,跟业务无关;数据字典表是用户可以动态扩充内容。它的分类用户不能改。分类是系统上线时,开发人员进行初始化。(分类是在代码中写死的,分类下的内容,用户可以动态扩充)
7.1.1字典设计
字典一般的设计是由类别+ID+名称
性别:0101男,0102女
包装单位:0201 PCS,0202 SETS
区县:02901西安市 02902宝鸡市
编码 名称 父编码 父名称 层级 是否叶节点 引用次数 备注 图标 排序字段 启用状态
首先这样设计的好处是,减少类别与数据的关联查询降低性能,其次如上所示ID编码规则方便切割与检索。
7.1.2字典使用
单选的组合;
下拉框;
8数据管理:
8.1 数据转储:
8.2 数据备份:
二 数据库设计原则:
1 范式原则
1) 表必须有主键
2) 字段内容不能是其他的字段加工而成
3) 行数据不能相同
设计案例项目一
优惠券系统E-R模型
业务描述:
通过对接支付宝平台辅助发送优惠券。通过支付宝平台获取更多的用户信息,通过用户信息
决定给用户投放什么样的礼包。一个礼包可以封装多种类型的优惠券。一种优惠券可以关联不同的
实体店商家,每一个商家可以有多种类型的优惠券。一个用户可以领券多种不同的优惠券。一种类型的
优惠券可能被多个用户领取。通过给用户出礼包,用户领取礼包里面的那种优惠券。对应的支付宝生成一张
优惠券。也就是说一种类型的优惠券可以生成多张不同的优惠券,而一张优惠券只能属于一种类型。
2反范式原则
1) 表不是必须有主键
2) 字段存一些加工后的中间的结果,冗余设计
3) 记录冗余
三范式追求的目标存储空间尽量小;反三范式追求的目标是查询速度。
创建数据库设计时首先按三范式设计,然后局部优化。
冗余查询:
select c.*,
(
select count(*) from yls_contract
) as ylc_num --这个查询结果当做一列
from yls_contract_c;
特殊设计:一对一
所有一对一关系使用相同的一个id,这样一个id就能获取所有的关联信息。
异构数据库,让程序支持主流数据库切换
| oracle | mysql | sqlserver |
设计 | PD针对不同的数据库采用不同的模型 | ||
字符串连接 | concat | concat | + |
日期 | to_char to_date | 日期字段可以按照字符串来处理 | cast convert |
分页 | rownum | limit | top |
程序开发时有要求:不能使用存储过程,不能使用规则rule,不能使用触发器;可以少量使用view。基于程序方便维护,程序通用性强,减少对数据库的依赖,增强程序代码的处理。也就是现今大多数软件公司都减少dba的角色,增强java代码来处理。
特例:但在大型项目中,分页采用存储过程。
实际开发中,由于这种底层封装效率太低,要做大量数据操作时或者大量连接查询统计时,spring jdbctemplate 直接访问数据。sqlDao封装spring jdbctemplate
分表技术
当业务数据量非常巨大时,常用的优化方式。一张表的数据量过大,这样在日常的操作时速度非常缓慢。怎么提高它的响应的速度,实际中就是将一些不常在使用的数据移动到另一张表中,而这另一张表叫历史表。历史表和原来的表结构一致。这样当前表由于只使用当前的部分数据,所以性能提高。因为实际业务中很少再去查询历史表,即使查询历史表由于使用的人也少,所以它的性能还能适应。
表结构一样,新创建表结果跟它一样
jdbcTemplate/sqlDao实现数据的批量新增(将当前表中的数据复制到历史表中),
批量的删除(将当前表的相关数据就全部删除)
3 大型项目设计方式
传统设计方式,基于对象关联,数据量小时,系统无碍;当数据随着系统的使用,线性增长,系统变的越来越慢,到达一定数据量时,性能急剧下降。
3.1打断设计(跳跃查询)
在表中增加一个字段,这个字段用来存储关联表的主键集合;主表中加入子表引用的主键集合,利用in子查询直接去查询子表,这样查询效率提高很多。而且数据量越大,查询效率越高。这种方式,业务关联层级越多,这种设计方式的性能体现越高。而且通过这种方式可以实现跳跃查询。
3.2冗余设计(数据搬家)
在某些字段的使用场景不是必须跟主键绑定的情况下,可以适当的抽取数据字段,到另一表中进行拼接,形成一个单表查询,这样可以就可以提高查询效率
三 对象设计
VO:视图话对象,做页面展示用
PO:持久化对象,做数据库存储用的
BO:业务逻辑对象,做复杂业务逻辑中间过程用的。
四 解决方案设计
一 导入导出技术预言
Poi是apache的开源组件,提供一套java的api对word、excel等文档进行操作。
使用HSSF进行excel文件写操作
HSSF只支持97-03版本excel,扩展名是.xls,每个sheet行数最大65536行。
缺点:如果写数据量大文件,可能会导致内存溢出,原因,将所有数据对象放在内存中,最后执行文件内容写。
优点:对于小数据量文件写操作,速度很快的。
使用XSSF对excel写操作
XSSF只支持07以上版本excel,扩展名是.xlsx(不向下兼容), 每个sheet对行数据没 限制。
优点:对大数据量文件执行写操作,不会导致内存溢出,原因,在写的过程中生成很多临时文件,一边写一边生成文件(内存中不会保留很多数据),最后将临时文件合并输出。
缺点:对大数据量写操作,速度不快。
二 导入设计
1: 做为导入弹窗弹出
2:有导入说明
3: 可以下载导入模板
4: 有文件选择框
5: 导入以后做数据校验,校验不通过给出校验分析报告方便用户修改
6: 批量插入保证与数据库的交互一次执行
三 导出设计
1: 做为导出弹窗弹出
2: 有文件下载选择框
四 解决方案
4.1 POI 导入文件格式excel或者cvs文件
4.2 文件导入先进行文件上传到服务器,服务器再读取本地文件进行导入
4.3 文件导出先从服务器数据库中导出数据,再提供下载