【Access小品】有关系？没关系？啥关系？

todaynew

　　版友小陈同志问了两个关于关系的问题，其一是“主键字段为文本型规范吗？”，其二是“表间全没有建立一对多关系好不好？对窗体、查询、报表的设计会带来什么影响？”

　　所谓关系是指事物之间的联系。朝鲜要与美日韩较劲，中俄跟着着急，这就表明这些国家间存在某种特殊的关系。这个世界事务和事情很多，所以关系也就无处不在无处不有。所以描述事物通常都需要描述关系，怎么描述关系呢？其实很简单，无非是有关系？没关系？啥关系？

　　闲话少说，书归正传。下面来解答小陈同志的两个问题。

　　第一个问题的解答：

　　1、主键的作用在于唯一性的标识记录，所以主键是什么类型的数据都可以，重点是每条记录上的主键值不能重复。

　　2、通常主键选用自动编号数据类型（实际是长整型，只是数据库做了自增的处理）较为妥当，其优点在于不必要另外写自动编码的函数。如果选用其他类型的数据，需要写一个自定义函数来解决自动编号的问题，已满足唯一性的要求。

　　第二个问题的解答：

　　1、在数据表设计时，设计数据表的关系并不是先决条件。所谓表间建立关系，实际上是建立表的约束条件，也就是说确定一个表是否依赖另一个表。我们不建立关系，也并不是不利用表之间的关系，否则的话数据的组织就无规律可循了。只是在于我们怎么样去表达这种关系而已。表达一个主表和一个子表之间的关系，我们大体可以有这么几种办法：

　　（1）通过关系视图建立表间关系；

　　（2）在查询的视图中建立表间关系；

　　（3）在VB中通过编写sql语句（常用语窗体或控件的数据源，或者ADO代码等），或者其子句（常用语筛选时）。

　　2、为什么通常都需要在关系视图中建立表间关系呢？其道理在于一旦在关系视图中设计了表间关系，在其后设计查询、校验数据等方面Access就会提供很多的自动的功能，也就是说你不必在多余写很多代码来解决这些问题。这能极大的提高开发和维护的效率。

　　3、凡事有利便有弊，有些情况下事先设计了表间的关系，也会带来很多的麻烦。举个典型的例子：假设我们有一个授课表，这个表会存在几个父表，大体应该有教师表、学科表、班级表。如果事先我们建立了授课表与其三个父表之间的关系。那么授课表的记录就会受到这三个表的同时约束，也就是，一条授课表记录，必须同时录入教师ID、学科ID和班级ID。这样的约束在现实中会出现问题，在安排很多教师的课程表时，几个方面的资源（师资、时间资源、学科资源、班级资源等）是不可能即刻确定的，可能需要反复调整。这样一种现实的情况，表示在录入一条授课记录时，总会有一些外键（教师ID、学科ID或班级ID）是不确定的。如果你又事先建立了表间的关系，那么这条记录你就没法录入了。

　　当然你可以采取一些变通的处理，比如在学科表中建立一个"待确定学科"记录，在班级表中建立一个“待确定班级”记录。这样确实能解决问题，不过你将为其他地方的处理花费代价，比如你需要在班级筛选学生时，过滤掉这条“待确定班级”记录等等。除了这种处理外，可能还存在其他基于建立了数据表关系后，对此类问题的变通处理。不过都会存在跷跷板效应，也就是说简化了一处，其它诸多地方繁琐了。

　　那么在诸如此类，一子多父的情况下，我们一般只事先建立一对父子关系，其他的父子关系，我们可以按照上述1中的一些办法来处理之。至于应该建立那一对父子关系，这就要看实际问题和你对问题的判断和考虑了。以授课表为例，应该建立的父子关系为教师表和授课表，其他两个父子关系大体不需要先建立。

yanwei82123300

谢谢分享心得{:soso_e179:}

ycxchen

授人以鱼不如授人以渔，老汉总能授人以渔，可敬。

roych

我一般很少在“关系”视图中建立关系，大多是在查询QBE里设置。。。既然老汉提到了主键，我也顺带说两句吧。
例如在设计一些人员信息表之类的问题上，很多人习惯用姓名作为主键。。。当然一般问题不大，但必须考虑到重名的可能性，因此正确的做法是用工号或者学号之类【身份证号码当然可以，不过这么私隐的东西不太建议使用】。
此外，必要的索引也是可以建立的，例如部门或者系院之类可以作为一个有重复的索引，这样更新查询或者追加查询时就不必写ADO代码来处理了【如果没建立关系的话，或者多对多关系，处理操作查询就很不方便了】。

ycxchen

我觉得在“关系”视图中建立关系还是有必要的，特别是对初学者，弄明建立关系的原理，对透彻理解表的相关设计很有益处，进而对查询及窗体的设计也有好处。例如，ROYCH版主所说的更新查询或者追加查询设计等。