请问这样算数据字典的方式么?
如果不是请问如果把我这个数据库设计成字典方式该如何设计呢?
请教了谢谢

解决方案 »

  1.   

    但是有点问题就是如图中第三张表的学历,籍贯,部门,这些数据类型都是int,
    由于没有和第二张表建立外键关系,
    所以这里容易在录入数据的时候写错ID导致籍贯里出现对应学历的BID.
    请问这样有什么方法解决么.
      

  2.   

    先谢谢你的回答按你说的这种方式
    我把第二张表分别拆分成
    ----------------------
    学历表
    学历ID  学历
     1      大专 
     2      大学
     3      博士
    ---------------------
    部门表
    部门ID   部门
      1       市场部
      2       公关部
      3       人事部
    -------------------
    籍贯表
    籍贯ID      籍贯
      1         湖北
      2         广东
      3         湖南-------------------然后把第三表对应的三列去和以上的三张表分别建立外键关系.这样在录入数据时候也会保证真确性.
    但是这样做的话似乎要多建几张表,那么这样话第三表是不是也算是字典数据呢?
      

  3.   

    我对数据库中的字典数据浅显理解大楷是这样,望指教.比如说一个用户表,需要包含很多信息有些是每个用户特有的例如生日,名字,年龄等这类.
    有些就是每个用户都有可能有的,例如籍贯,学历,这些等.
    那么通常我们解决这样的方法是分别建立籍贯表,学历表,
    然后把用户表建立对应的ID去和这些表建立外键关系,
    也就是说在用户表填写到学历这个列的信息时,只需要获取对应学历的ID,
    这样做当然好处便于维护,那么这个用户表是不是就可以说是这个数据库中的一个字典数据呢?
    请指教
      

  4.   

    个人觉得第三张表没必要用ID关联。楼主的第一,二两张表只是为了程序显示和管理的方便。
    但是第三张表纯粹为了存数据。因此,建议还是直接存BINFO就可以了。
      

  5.   

    看到这儿想起了数据库范式了。 
    回顾一下:
    1、一个Table中的列不可再分
    2、一个Table中的行唯一标识
    3、一个Table不包含已在其它Table中已包含的非主关键字信息
    希望对楼主的问题,有所参考!
      

  6.   

    关于数据字典一般有两种形式:
    一. 如4L所讲: dd_学历, dd_部门, dd_籍贯 ...
    二. 类似LZ的形态:
    create table userDataDict (
    domain int not null, -- 字典域
    dictid int not null, -- 字典条目
    descript varchar(64), -- 条目含义
    primary key (domain, dictid)
    )
    insert into userDataDict values (0,1,'学历'),
    insert into userDataDict values (0,2,'部门'),
    insert into userDataDict values (0,3,'籍贯'),
    ..
    insert into userDataDict values (1,1,'中专')
    insert into userDataDict values (1,2,'大专')
    insert into userDataDict values (1,3,'大学')
    insert into userDataDict values (1,4,'硕士')
    insert into userDataDict values (1,5,'博士')
    ..
    insert into userDataDict values (2,1,'Service')
    insert into userDataDict values (2,2,'Market')
    insert into userDataDict values (2,3,'Sales')
    insert into userDataDict values (2,1,'TechSupp')
    ...
    insert into userDataDict values (3,1,'北京')
    ...
     
      

  7.   

    这种观点在MySQL里实现比较好,因为其中有个enum字段类型,可以在表结构中直接存数据字典;但在无enum字段类型的数据库系统里,建议还是要有字典表比较好。
      

  8.   

    1. 字典是一种key-value结构,通过key可以快速索引到value. 从这个角度讲,第三张表是一种字典,--一种异构字典,其值由多个不同的属性组成;通常意义上的字典,其value是简单的说明性的。
    第三张表这类,一般被称为"基本信息表"
    2. 数据库系统本身并不介意你多建了几章表,但如果系统非常复杂,字典种类奇多,14L的第二种方案也是常见的选择。
      

  9.   

    可惜啊,已经结贴了。
    其实有更好的解决方法,就是把第一张和第二张表合成一张表,
    通过id指向 父id 即可,
    这样做在新建用户时,选择 下拉列表框 就很方便去DB查询,也不会出现,
    当然了减少了表的个数。。