2 mars9527haha mars9527haha 于 2014.12.15 13:28 提问

有关审核表设计上面的,求方案【在线等】

业务是“资料审核”,审核会出现多次不通过的情况;
现在有两张表,一张company_info(公司信息),一张check_company_log(审核日志),如果审核不通过的情况下,要给用户看到不通过的原因;

目前的设计是check_company_log表里面有“原因”字段,company_info表里冗余一个“原因”(用于展示,当然这里面存的是最后一次不通过的原因)

每次不通过的时候,要做两个操作,先把company_info里的原因更新,然后给check_company_log里面存一条,看有没有更好的办法,从表的设计上把两步简化

求高手优化

4个回答

devmiao
devmiao   Ds   Rxr 2014.12.15 14:32

关键要看你怎么优化,如果不是出于性能的考虑,可以对log表按照用户做索引,然后直接取最新的一条作为原因,这样就不需要那个字段了。

lowanty
lowanty   2014.12.15 13:49

在company_info表中冗余一个”原因”的目的是什么,是为了方便查询,还是快速查询。。。待审核的公司数量有多大,审核通过后是在log表中记录一条审核记录就行了,还是需要修改info表中的某个字段?

通常审核多次流水追溯的问题,不建议把失败原因放到info表冗余。info表只需要记录一个审核状态就行了,多数情况直接记录log;审核完成后记录log的同时修改info状态字段

lowanty
lowanty   2014.12.15 13:49

在company_info表中冗余一个”原因”的目的是什么,是为了方便查询,还是快速查询。。。待审核的公司数量有多大,审核通过后是在log表中记录一条审核记录就行了,还是需要修改info表中的某个字段?

通常审核多次流水追溯的问题,不建议把失败原因放到info表冗余。info表只需要记录一个审核状态就行了,多数情况直接记录log;审核完成后记录log的同时修改info状态字段

lowanty
lowanty 回复mars9527haha: 那么设计改成这样,log表是你的操作日志。 业务只有info一张表,原因和状态都在info表里面。。。log表是辅助用的,可以用日志系统代替。。。这只是换了一个思考角度;这样的话,设计上会回到你现在的设计方案。但是概念上你需要注意,业务只有info这一张表,log只是日志;不在业务中提供使用,仅供管理员查看。可以考虑用通用日志系统代替你的log表设计。。。从思想上你不应该把info中的原因理解成冗余。
3 年多之前 回复
mars9527haha
mars9527haha 回复lowanty: 不追溯,用户只看到自己最后一次提交失败的原因;能看到整个审核历程的只有我们后台的管理员(查看log表)
3 年多之前 回复
lowanty
lowanty 回复mars9527haha: 你可以看下数据库的设计范式,参考第三设计范式
3 年多之前 回复
lowanty
lowanty 回复mars9527haha: 你可以看下数据库的设计范式,参考第三设计范式
3 年多之前 回复
lowanty
lowanty 回复mars9527haha: 失败原因要求追溯历史失败原因吗?意思就是第一次失败原因:“企业名称错误”,第二次失败:“企业执照错误”。第二次时能看到第一次失败的原因吗?或者在其他地方能看到整个审核历史过程。数据量不大就没有必要冗余原因到info表了,两张表的事务处理也是有开销的。。。看你的需求应该是一个也没就显示一个企业信息了,最多也就20来个;这种情况下查询的时候多查一个表是没有什么问题的(可以连表,也可以查两次)。
3 年多之前 回复
mars9527haha
mars9527haha 其实整个流程类似在360手机助手上提交app,如果他们后台审核没有通过,我会看到失败的原因,当我再提交之后,如果还是没有通过,仍然可以看到失败原因,现在就是这个“失败的原因”看怎么设计 1.出于性能考虑,避免关联查询,所以在company_info中冗余了"原因",用户在审核的结果页面展示失败原因时候,我直接查company_info,就可以了,带来的问题就是,如果再次提交资料,审核仍未通过,这时候得先修改company_info的“原因”,然后再给log表里面插入一条; 2.目前整个的数据量都不是很大; 3.审核通过后做两件事:修改company_info的状态为1(通过),同时在log表插入一条记录;
3 年多之前 回复
mars9527haha
mars9527haha   2014.12.15 14:01

其实整个流程类似在360手机助手上提交app,如果他们后台审核没有通过,我会看到失败的原因,当我再提交之后,如果还是没有通过,仍然可以看到失败原因,现在就是这个“失败的原因”看怎么设计
1.出于性能考虑,避免关联查询,所以在company_info中冗余了"原因",用户在审核的结果页面展示失败原因时候,我直接查company_info,就可以了,带来的问题就是,如果再次提交资料,审核仍未通过,这时候得先修改company_info的“原因”,然后再给log表里面插入一条;
2.目前整个的数据量都不是很大;
3.审核通过后做两件事:修改company_info的状态为1(通过),同时在log表插入一条记录;

Csdn user default icon
上传中...
上传图片
插入图片
准确详细的回答,更有利于被提问者采纳,从而获得C币。复制、灌水、广告等回答会被删除,是时候展现真正的技术了!
其他相关推荐
审批流程设计方案-介绍(一)
10年有幸接触了HP的一套PAAS平台,里面有一套关于工作流、审批流的设置模块。公司现在做的这个项目也有用到审批流。这中间磕磕碰碰的遇到不少问题,但最后也小有收获,趁着周末闲暇时间,把一些细节方面上的事分享出来,一来是对前期的工作有个总结;二来抛砖引玉想多听听大家的意见,开拓开拓思路,和大家共同成长进步。 先来看看关于工作流、审批流的定义: (1)PAAS平台工作流&审批流的定义: 工作流:
自定义审批流程表设计
 我想开发一个OA的自定义审批流程,但对表的设计感觉怎么也设不好,好像达不到想要的效果。我把表设计贴出来,大家帮忙看看,给点好建议。流程模块表,我会在后台手动建立,就是那个表的资料要进来审批,那就要在这里先建立,页面上会有相同的标识,这样可以让系统自动识别这个资料的相关审批流程。
审批流程设计方案-数据(二)
接着上面一章我把数据库的表结构给出。 第一:流程定义表A_FlowTable(ID,流程编码,创建时间,创建人,流程名称,启用状态,锁定状态,撤销状态);锁定状态:审批结束锁定表单;撤销状态:是否允许撤销;我们现在使用的设计模式把对应的关联表单放在了第三中,其实可以把审批流程关联的表单放在第一中; 第二:流程节点图形位置图A_FlowPointXY(ID,流程ID--flowid,节点ID--
通用流程化应用审批单设计思路(一)
本文为通用流程化应用审批设计思路表单部分。
数据库基础、原理、优化操作及方案
MySQL数据量大时,优化可以进行的操作:MySQL分库分表,MySQL缓存,MySQL索引,MySQL优化查询语句? 其他数据库也类似,只是有些数据库的特性不一样。数据库优化方案:缓存;数据库表的大字段剥离;恰当的使用索引;表库的拆分;字段冗余;从磁盘上做文章;放弃关系数据库的某些特性等;主机性能;内存使用性能;网络传输性能;SQL语句执行性能。数据库优化方案- http://database....
基于PaaS平台开发流程审批框架界面设计方案(草稿)
1、概述         基于PaaS平台开发流程审批业务功能,首先要体现云计算PaaS平台的特性,例如多租户、统一平台、技术规范等。因此,为了达到快速、规范化开发业务功能的要求,在此设计流程审批界面框架,对业务数据和流程数据进行解耦。 2、流程审批界面需求分析 2.1、审批界面样例分析         1、以审批意见为主体关注点的审批界面,例如下图所示公文审批稿签界面,在业务流转过程中,
数据库中状态表的设计
昨天在系统内部业务培训时,讲到了采购业务中供应商状态的变迁历史,随着公司业务的变更,系统的状态表中的供应商状态不断的增加了。 虽然如此,但是由于我们在设计之初据考虑到以后的可扩展性,所以我们的状态是不连续的,比如新建状态是1,审核状态是11,作废状态是否-1 等等。          这样设计虽然保证了一定程度上的可扩展性,但是对于这些不需要的状态我们在系统中有些地方我们可能就不需要选择了,
自定义审核流程(二)
执行审核上则是每处理一个环节,就插入一个环节的信息. 我个人认为实现审核的代码使用存储过程去实现要比用C#代码去实现要好,至于用事务处理感觉还是差点,因为如果一个系统的事务处理过多,会造成处理缓慢,而用C#代码去实现,则需要进行多次的查询数据库,操作过程也比较复杂..所以我觉得还是用存储过程去实现是最理想的.  1 Create    procedure  Ex
OA系统中 流程审批数据库的设计
参考: http://www.cnblogs.com/kingeric/p/6052826.html
进销存设计与分析_采购订单(4)
一、目的:    让用户根据销售情况和库存状况录入采购订货的数据;二、主从表显示:    主表显示:单号、供应商、部门、制单日期、制单人、审核人、审核日期、作废人、作废日期、单据状态    从表显示:商品编号、商品名称、单位、数量、单价、金额、仓库三、功能    功能键:添加,修改,删除,保存,撤消,审核,反审核,作废,打印四、从表的单价取值顺序:先从进仓单里取(商品id+供应商)->