字典表设计

================================================================================================================================

字典表设计及应用举例      为了响应志峰兄弟的需求,今天抽了点时间写点关于字典表设计的东西,顺便结合一个小的应用对设计做个用例体验。
咱先来看看什么叫字典。
     时间紧张,先略了,以后再谈呵呵
字典存在的必要性及他的好处。
     同上^_^
字典设计思路。
     字典信息在系统中充当基础参数的角色,基本上有些重要的基本信息是要在系统在为正式业务服务之前就由系统管理员维护进去的,有的字典信息是在使用过程中由系统管理员或者其他用户维护进去的。

也就是说,我们有“维护字典信息”的需求,那么我们在设计字典信息表结构的时候就要考虑到这个需求。
     在维护的时候,我们肯定希望能对字典信息分文别类的进行维护,这样我们需要设计一个字典类类别表(Dic_Type),结构如下:
     ID(字典类型ID) 
  Name(字典类型名称)

具体表数据特征请看下面的例子。
     有了类别表后,我们还需要一个存放每个类别的字典信息的具体数据表(Dic_Data):\

ATID(自动增长的ID,没有实际作用) 
  TypeID(字典信息归属的字典类别ID)
  ID(字典信息ID,在程序中使用的字典ID就是这个)
  Name(字典信息内容)

这样,在我们的业务信息表中,存放的和字典相关的字段的值就是Dic_Data中的ID的值,那么就涉及到在界面上显示信息的问题,如果不做处理,显示出来的肯定就是原始的字典信息的ID,肯定不是用户希望得到的,基于这个需求,
  我们为每个类型的字典信息做一个视图(具体方法见后面的例子),
  将信息表与对应的视图做关联查询就可以得到字典信息ID对应的真正内容。

应用举例。
     假定做一个学生信息管理系统
     字典类型表设计如下(Dic_Type):
     ID Name
     1  Sex
     2  ...

字典内容表设计如下(Dic_Data):
     ATID TypeID ID Name
     1    1      1   男
     2    1      2   女
     3    2      1   ...
     4    2      2   ...
     5    2      3   ...
     6    2      4   ...
    ...  ...    ...  ...

性别类型字典的视图(VW_Sex):
     select ID,Name from Dic_Data where TypeID=1

假设学生信息表如下T_Student:
     ID Name  ... Sex
     1  采采  ...  1
     2  花花  ...  2
     3  刚刚  ...  1

取学生列表信息可通过如下方法实现:
     select T_Student.ID as StudentID,T_Student.Name as StudentName,VW_Sex.Name as SexName
     from T_Student left join VW_Sex on T_Student.Sex=VW_Sex.ID

结果如下:
     StudentID  StudentName  SexName
     1              a            男
     2              b            女
     3              c            女

时间仓促,写的粗糙了点,还请见谅,有时间再补充。。。

绿色通道:好文要顶关注我收藏该文与我联系

================================================================================================================================

我们现在在进行数据库字典表设计时,有二种方式,其一是传统的方式,每个字典表都有ID、Name两字段。第二种方式是将所有字典表的数据放在同一张表中,结构如下:

TypeTable(typeID,typeName)【主表,用来记录字典表表名信息】;DataTable(typeID,DataId,DataName)【从表,记录所有字典表数据信息】

如性别、婚姻状态,在TypeTable中是两条记录,{02,性别},{06,婚姻状态};而在DataTable中各有三条记录{02,0,女 / 02,1,男 / 02,9,其它},{06,0,未婚 / 06,1,已婚 / 06,9,离异}

另有一张病人列表patient(patientID,SexID,MarryStatusID…)

现在需要查询病人信息,sql语句如下:

Select b.DataName as SexName,c.DataName as MarryStatusName

from patient a left join DataTable b on b.DataId=a.SexID and b.typeID=’02’

left join DataTable c on c.DataId=a.MarryStatusId and b.typeID=’06’

在数据库中执行该Sql语句,由于DataTable约1000条左右的数据量,相对第一种方式必将对数据库有一定的影响。

(当然在实际业务中可能类似的字典表约达5-10个,patient的数据量约500w条)

但不知道在一个系统中所有字典表获取数据都采用这种方式对数据库性能到底影响到什么程度,约降低百分之几的性能?会有其它隐患没?

================================================================================================================================

楼上的可能没明白楼主的意思。

不是指学历表和国籍表数据量大,而是指人员表所具有的属性可能太多(这里不一定指人员表,也可能是其它的实体,即随着系统的复杂程度增加,实体的属性增加)。这里以人员为例,说了国籍和学历两个属性,如果人员还有职位,那么必然多出职位表,如果还有其它...

那即,当取得一条实例的完全数据时,那将进行几十个表的join,楼主考滤的应该是这个问题。

person_info(person_id,name,country_id,education_id,position_id,....) 
country(country_id,name,...) 
position(position_id,name,...) 
education(education_id,name,....) 
...

所以楼主采用了另一种设计方式: 
所有属性类(属性本身也是实体,只不过是主表的某个属性)放置在一个表中,用属性名和属性值来区别。 
persion_info(persion_id,name,...) 
1 aaa 
2 bbb 
attributes(attributes_id,persion_id,attributes_name,attributes_value) 
1 1 country china 
2 1 education 小学 
3 1 position 公司总裁 
4 2 country usa 
5 2 education 硕士 
6 2 postion DBA

字典表设计

时间: 2024-11-14 15:40:26

字典表设计的相关文章

数据库字典表设计

在稍大一些的项目中,我们总是需要管理各种各样的类型类型数据(如商品类型.游戏类型...).对于这些类型的管理类似,如果为每 一种类型都建立一张表去维护(而在项目中,正常出现50种类型),那工作量是可想而之大,并且我们不得不去了解每一个类型表的名字, 以去关联它. 因此,我们需要一种数据模型以完成对多种多样类型管理的需求. 字典表dictionary 字段名           类型               是否可空    中文名         描述 dict_name    varchar

Java Web项目实战记录(数据库表设计)

又是忙到这个点 虽然累,但是看着自己的项目在一点一点的成长,心里满满的成就感>_< 今天上了一下午的cep(职场社交礼仪规划课程),是不是职场就像cep老师说的那么的勾心斗角呢? 所以今天并没有做了多少东西,数据库的文档已经出来了,但是不是太详细,表之间的关系并没有说的太清(数据库的设计我并没有参与) 以下是数据库的文档: --------------------------------------------------------------------------------------

数据库表设计的很灵活,是否做SQL语句也那么容易呢

由于项目需要,我们把一些不经常变的常数通过数据字段配置好,系统初始化的时候通过数据库字段去更新数据.下面就实例说明. 我有一张这样的表 ,你会发现meterkindid和measureid是代码,只有通过数据配置的数据字典才能解析出我们要的值,下面为数据字典表结构 ,这样设计就很灵活,FieldID为列名称,ID为上面表的值,value为解析值,也就是代码对应的名称,下面再发一张字典的数据图 MK001和MK002对应数据字典的水表跟电表,MS001和MS002对应数据字典的计量单位分别为吨还是

jdbc如何优雅的解决字典表数据转化

我们在做数据库设计的时候肯定会用字典表或者说枚举表等固化数据,那么当查询数据的时候用到了这些字典值的时候我们会怎么做呢.以下举个栗子吧,不对应该是好几个栗子 字典表(PUB_RESTRICTION) SERIAL_NO DESC_ID DESC_CHINA KEYWORD 67550001 1 城区 AREA_TYPE 67550002 2 郊区 AREA_TYPE 67550003 3 县城 AREA_TYPE 67550004 4 乡镇 AREA_TYPE 用户表(MANA_USER) US

如何通过字典表来获取下拉数据的实现

①在web.xml中添加监听,启动的时候初始化. <!--Web ApplicationContext 载入,继承处Spring的ApplicationContextListener --> <listener> <listener-class>cn.sccl.common.web.StartupListener</listener-class> </listener> ②我们需要在启动Tomcat的时候,初始化bizCode数据 package

MySQL的多表设计

一.外键约束 保证数据的完整性. 定义外键约束: 可以直接在create语句中定义外键 foreign key 当前表名(字段名) references 目标表名(目标表的主键) 创建完语句后,可以直接使用修改语句定义 alter table 表名 add foreign key 当前表名 (字段名) references 目标表名(目标表的主键) 二.多表设计的三种实体关系 多对多.一对多和一对一 三.多表设计之---------一对多 一个班级可以有多个学生,但是一个学生只能属于一个班级.或

php不用递归完成无限分类,从表设计入手完整演示过程

无限分类是什么就不废话了,可以用递归实现,但是递归从数据库取东西用递归效率偏低,如果从表设计入手,就很容易做到网站导航的实现,下面是某论坛导航,如下图 网上无限分类大多不全面,今天我会从设计表开始, 首先我们先做视图界面, <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>白超华-博客园</title> &

mysql中的索引原理与表设计

索引是有效使用数据库的基础,但你的数据量很小的时候,或许通过扫描整表来存取数据的性能还能接受,但当数据量极大时,当访问量极大时,就一定需要通过索引的辅助才能有效地存取数据.一般索引建立的好坏是性能好坏的成功关键. 1.InnoDb数据与索引存储细节 使用InnoDb作为数据引擎的Mysql和有聚集索引的SqlServer的数据存储结构有点类似,虽然在物理层面,他们都存储在Page上,但在逻辑上面,我们可以把数据分为三块:数据区域,索引区域,主键区域,他们通过主键的值作为关联,配合工作.默认配置下

ERP开发分享 1 数据库表设计

这是我的ERP设计经验分享系列,今天讲的是数据库的表设计(1),主要阐述: 1.单字段的主键:2.使用int32作为主键类型:3.使用版本字段处理乐观锁定:4.生效字段标明是否允许“被使用”:5.锁定字段处理悲观锁定:6.行唯一字段处理分布式应用: