这样的数据字典如何设计？

例如“职员”类有一个“国籍”属性和一个“学历”属性，于是就需要有一个“国籍”类、一个“学历”类，对应的数据库中也需要一张“国籍”表、一张“学历”表。“职员”类则需要包含一个对“国籍”的引用和一个对“学历”的引用，对应的数据库中“职员”表中也需要两个外键分别指向“国籍”表和“学历”表。这样的设计在类似“国籍”和“学历”这样的公共信息比较少时是可行的，但是随着系统复杂性的增加，系统中会出现大量的结构类似的信息表和信息类，数量一直会到达一个不可接受的地步。
　　上述问题的一个特征是：这些信息类的内容都是需要动态维护的，但是所需的属性是一样的，对应的数据库表中包含的字段也是一样的。关键的字段就是两个：“标示”和“名称”，“标示”用于表示不变的主键，“名称”用于表示程序界面上显示的文字。
　　“系统代码”就是为了解决上述问题而设计的。在“系统代码分类表”中我们放入一条记录：“countrys，国籍”，然后在“系统代码表”中增加具体的国籍数据，比如：“countrys_china，中国”、“countrys_usa，美国”等等，这些具体的国籍信息的“代码分类”字段都指向“代码分类表”中的“countrys”分类。这样，在程序需要获得国籍信息时，只要通过“countrys”这个标示去“系统代码表”中检索就可以了。这样的设计也便于建立一个单独的程序模块来维护所有的这些公共信息。
不知道这样的设计，有什么好处，查询一个国籍还要知道关键字是“countrys”
请教，大家的系统里这样的代码表是如何设计的？

这个设计有好多好处，举个最简单的例子．
对于一个下拉列表，如果你不采取这样的试式，
你就需要手动的把这些值打到页面上．如，

国家，你需要手动的把所有国家的代码都敲到页面上，先不说效率的问题，你要敲多久，还有，
如果有一天，像南斯拉夫，那个时候，突然国家换名了，你是不是要所有涉及的页面都要手动的改一变呢／
还有一样，如果有一点你发现，你的一个代码的名称需要换一个，你是不是要到你的数据库中把以经存在的所有数据都更新一遍呢？
如证件，身份证，有一天就想叫居民身份证，你原来如果没用数据字典，你是不是就意味着，要把身份证这几个字存到你的一张信息表中呢
其实除了上面的这些，个人开发久了发现还有一处，那就是整理出一个好的数据字典，就意识着简化了你的主表的页务逻辑和变更的机会，使你的系统更稳定．这样的设计才是可取的．
一，　使你的数据库更可维护．

二，　使你的主表更稳定不需要频烦的改动．特别是数据量大的时候．

三，　有利于你的页面层业务逻辑判断．

四，　这样的表结果条理上更清楚，更容易理解，在可开发性，可扩展性，可维护性，强状性，上都有优势．你看过程序设计吧，什么样的程序才是你的所选．因为，需要的情况下，一定要做数据字典．

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

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

那即，当取得一条实例的完全数据时，那将进行几十个表的join,楼主考滤的应该是这个问题。
你说对了，这样设计的系统代码表已经很普遍了，这样的方案有很多，我上面具的例子，不太好，问下大家有没有其他方案。
楼上那位没有明白我的意思，还停留在初级阶段。

个人觉得这种设计灵活性高。但效率肯定是差的。

通用的东西，效率都好不到哪去。需要讲究量体裁衣。

至于具体的系统里怎么设计，还是要在看实际情况来找寻二者间的平衡。无论怎么做，范式仍是基础。

应该是这样设计的。我在的公司，就是这样设计的。
这些数据相对固定，且需要大量使用，采用数据字典的效率会比单纯的table要好。
但这样的效率提升前提是 数据要大量使用.......不然会适得其反。
这就好比存储过程和普通的SQL语句的差别

基本上是这个概念，各自的实现方式就五花八门，有的还会建一个系统常量表，比如 男 1女 0 之类的，不关联，备忘。

来源：nba直播