您的位置:首页 > 数据库

关于数据库中客户基本资料存储信息分类的设计说明

2003-02-14 08:58 746 查看
关于数据库中存储信息分类的设计说明

关于数据库中客户基本资料存储信息分类的设计说明

在进行系统数据库设计时,经常使用对客户基本资料的分类处理,如对商业客户的分类处理,一般的设计人员可以使用下面几种方法去实现:


1).直接在对客户进行编码的过程中,把客户的分类信息编写到客户代码中;
利用系统维护的分类代码信息进行代码编写,在代码的特定的代码位具有特定的分类信息,例如: 11 01 00
01 001 客户商业类型 客户地区代码 客户….. ….. 客户序列号

这种方式的表结构可以这样设计:














使用这种方法的好处有: a.通过代码可以了解客户的大概情况
b数据库中表结构的定义比较简单
c.对客户进行统计分析直接对客户代码处理,处理过程简单好控制
使用这种方法的缺点有: a.用户对客户进行编码时,必须要准确了解客户的详细分类信息
b.客户性质发生改变时,要改变客户代码非常困难
c.客户代码比较固定,一但定义且被其他业务模块使用后就不能重新修改
d.无法修改客户分类规则,无法增加删除分类信息,一般最终用户对其客户的分类方法会根据其具体的业务规模大小进行客户分类设计,小型企业和大型企业的客户的分类方法肯定不会使用相同的分类方法,这样系统的灵活性能是最差的


2).在客户基本资料表中增加分类栏位,客户代码使用简单的序列编码方法实现;
这种设计方法是现在应用系统中最常用的数据库设计方法,客户代码已经失去的具体的含义,只是在建立客户基本资料的系统产生的序列号,没有其他任何的含义;当然也可以在客户编号中保留通用的较少的分类信息,但是越少越好。在表中定义一些存储分类信息的栏位,如:客户所属地区码,客户分类码,客户规模码,客户信用类别,等等栏位。在系统设计时可以尽量的考虑到用户可能使用的所有的分类情况,用户最终使用不使用由用户根据自己的特定情况的处理,可以选择部分栏位。

这种方式的表结构可以这样设计:

















使用这种方法的好处有: a.客户代码定义比较简单,不需要客户基本资料录入人员对客户具体的分类情况特别了解,可以先保持分类代码缺省和大概的分类
b.系统的灵活性比较高
c.客户性质发生变化时,对系统的影响比较小
使用这种方法的缺点有: a.表设计比较困难,设计人员要考虑的比较全面,各种分类情况都要通过相应的分类栏位实现
b.在系统详细设计和代码实现阶段的工作量比较大,因为要考虑用户可能使用那几类分类方式,而且对不同的分类要做相应的代码实现,代码的通用性比较差
c.在未知的将来,如果存在未考虑的分类情况,则系统需要维护
d.表与表之间的关联(References)比较紧密,因为客户基本资料表的访问几率是比较高的,太多的关联一定会导致系统运行速度,很容易产生表间互锁现象



3).使用分类代码表
在这种设计结构中,把客户基本资料中的分类信息和不可分类信息分开处理,可以通过分类处理的信息通过专门的分类代码表存放,在客户基本资料表中只存放一个分类代码表中的索引号(代码表中的主键)。在分类代码表中,改变原来的每个分了占据一个栏位的竖向方式为每个分类占据一条记录的横向方式,可以正对不同的资料有针对性的具体分类方法。
客户基本资料表中,客户代码使用第二种方式的客户代码编码方案,用户需要对客户进行分类归档时,可以进入分类归档模块进行处理,把基本资料维护和分类归档信息维护分步处理。

这种方式的表结构可以这样设计:


















使用这种方法的好处有: a.客户代码定义比较简单,不需要客户基本资料录入人员对客户具体的分类情况特别了解,可以先保持分类代码缺省和大概的分类
b.系统的灵活性高,可以随时维护客户的分类代码信息
c.客户性质发生变化时,对系统的影响非常小
d.系统在访问客户资料表时根据是否需要查询分类信息而自由的设定是否关联分类代码表
e.系统中的所有分类归档信息可以统一管理
使用这种方法的缺点有: a.在系统数据库设计的工作量比较大
b.数据的维护查询过程比较复杂,因为涉及到多张表的关联,故执行效率可能会降低


在进行系统的多层架构设计时,可以使用第三种方法。前端表现层只负责和用户的界面交互工作,关于业务逻辑处理在中间业务逻辑层进行处理,数据存储层负责数据存储工作。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐