关于数据库的变更设计的思考随笔

WBOY
發布: 2016-06-07 15:35:57
原創
1068 人瀏覽過

11数据库中表结构的变更总是一件让人感觉不舒服的事情。 在新增加字段时,如何对以前的操作不产生影响或者将影响降至最低呢? 一种方法:直接在表上增加一个字段,给该字段设置一个默认值,该默认值用于标记以前的数据,然后用新的值来标记以后的数据。 如果

11数据库中表结构的变更总是一件让人感觉不舒服的事情。
在新增加字段时,如何对以前的操作不产生影响或者将影响降至最低呢?
一种方法:直接在表上增加一个字段,给该字段设置一个默认值,该默认值用于标记以前的数据,然后用新的值来标记以后的数据。
如果说是标记的话,那么为什么不在设计的时候就专门建立一个字段,来作为数据的版本标识呢?
但是问题好像没有这么简单,比如:在His系统的设计中,有关科室人员的设计,在最基础的版本中,只需要有科室人员的姓名,登陆密码,编号,所属科室等信息就够了。但是如果医院领导要求在更大的范围内对医院进行信息话的管理,那么在科室人员数据的设计上,就要再增加新的内容,比如:出生日期,家庭住址,学历,职称,是否是党员等等,这些数据该如何处理呢?是重新设计数据库吗?

在设计数据库的时候,里面的数据流程也是数据的生长轨迹,可否专门对生长轨迹进行处理来简化数据流程的处理呢?
用流程数据来代替标记数据。
如:chufang_mx表中,bz为标记该处方的状态:1-划价,2-收费,3-取药,4-退药,5-退费审核,6-退费。
用流程数据表示:建立一个用于维护处方数据流程的表chufang_lc(chufangid, hj,sf,qy,ty,tfsh,tf),每完成对该处方的处理,就将对应的流程数据置为1。作为流程,只要判断当前流程是否处理及上一流程是否处理,就可以知道是否可以处理当前流程。这样就可以轻松维护数据流程了(我现在实在厌烦在数据库的设计文档上标记各种状态值的含义,还有就是判断当前的处理是否满足流程要求,有没有跨过流程处理的可能性。)

对于以上设计,按照数据库的设计原则,可以设计为两个表:流程记录表(流程记录id,流程描述),流程记录明细表(流程记录id,流程记录序号,流程步骤描述,流程执行标记(布尔值)),这两个表中的数据和业务数据对应。
再加上两个流程维护表:流程信息表(流程id,流程描述),流程信息明细表(流程id,流程序号,流程步骤描述)

对于流程维护表,其信息也可以将其绑定于处理这些数据对象上,因为同一个数据集,其处理对象不同,就意味着其处理流程不同,并且可以为处理对象的各个方法标上流程中的处理序号,这样就可以轻松判断处理对象上的某个方法当前是否可以处理他对应的数据了。

对于流程,为什么不直接在设计某个实体的时候,直接给他加上流程编码呢?比如给处方表加上lc,那么定义:lc=1时,处方划价;lc=2时,处方收费。这样也可以体现流程信息。

经过几天这几天的思考,发现同一个数据,在系统流程的不同环节,对其的描述不一样.这就有一点像在现实生活中,对同一个人,处于不同环境的其它人对它的描述肯定不一样。而对于这个描述,其特征应该是复合的,即对于这个人的描述是综合了这个人的一个或者多个特征的组合来完成的。比如说:老师说小明是一个好学生,那么老师说这句话的时候,老师的大脑里一定出现了小明平时的几个特征:上课专心听讲,积极发言,认真完成作业等等。而小明的妈妈说小明是一个乖儿子,妈妈在说这句话的时候,大脑里出现的是小明的其它特征:有孝心,成绩好,能够体谅妈妈等等。这就说明,一个对象在对另一个对象进行处理时,是综合了它的特征的。那么就是说,对象应该有一个它的特征列表,这个特征列表是这个对象在处理中的前提。
呵呵,这个好像有点像游戏设计了。其实在处理商业逻辑中,也应该是这个道理。把那些分散的标记管理起来,然后对商业的逻辑对象进行处理。

根据以上思路,必须在系统中注册各个对象的描述,这些描述是系统数据处理的依据,它对了对象的特征集,而对象的每一个特征都有相应的处理方法。

來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板