Linux下DHCP服务以及DHCP中继代理服务的实现

[align=left]主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。 [/align]
必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境，就很难对这些键进行修改，所以在开发阶段就设计好主键和外键就是非常必要和值得的。
主键：
关系数据库依赖于主键---它是数据库物理模式的基石。主键在物理层面上只有两个用途：
1. 惟一地标识一行。

2. 作为一个可以被外键有效引用的对象。 http://www.mscto.com 基于以上这两个用途，下面给出了我在设计物理层面的主键时所遵循的一些原则：

1. 主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。
2. 主键应该是单列的，以便提高连接和筛选操作的效率。
软件开发网

注：使用复合键的人通常有两个理由为自己开脱，而这两个理由都是错误的。其一是主键应当具有实际意义，然而，让主键具有意义只不过是给人为地破坏数据库提供了方便。其二是利用这种方法可以在描述多对多关系的连接表中使用两个外部键来作为主键，我也反对这种做法，理由是：复合主键常常导致不良的外键，即当连接表成为另一个从表的主表，而依据上面的第二种方法成为这个表主键的一部分，然，这个表又有可能再成为其它从表的主表，其主键又有可能成了其它从表主键的一部分，如此传递下去，越靠后的从表，其主键将会包含越多的列了。

3. 永远也不要更新主键。实际上，因为主键除了惟一地标识一行之外，再没有其他的用途了，所以也就没有理由去对它更新。如果主键需要更新，则说明主键应对用户无意义的原则被违反了。
注：这项原则对于那些经常需要在数据转换或多数据库合并时进行数据整理的数据并不适用。
4. 主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等。
5. 主键应当有计算机自动生成。如果由人来对主键的创建进行干预，就会使它带有除了惟一标识一行以外的意义。一旦越过这个界限，就可能产生认为修改主键的动机，这样，这种系统用来链接记录行、管理记录行的关键手段就会落入不了解数据库设计的人的手中。
我认为主键可以分为两种，一种是无意义的主键，例如News表中的NewsID主键，目的只是为了唯一标识一条记录，如果数据表中去掉这个主键字段，该表中的信息也是完整的，也就是说该字段对用户是透明的，用户理不理解都无所谓;一种是有意义的主键，比如Orders表中的OrderNO主键，这个表是离不开OrderNO这个字段的，这个字段已经成为业务实体的一部分了，这在做系统分析的时候就已经确定了，它对用户来说是可理解的，甚至是需要记忆的。

　　有意义的主键是需要自己写程序或者建立专门的数据表来生成的，而且生成的规则也是在系统分析的时候就确定好的;对于无意义的主键则根本没有这个必要，下面我列出了一个流程步骤来说明怎样给数据表分配一个主键：

　　1、数据表一定要有主键，该主键可以是一个或者多个呵呵，废话一句

　　2、数据表的主键选择首先在该数据表自有的字段中找，依据是该字段或者字段组合可以唯一的标识一条记录，好像也是废话

　　3、如果在自有字段中实在找不到可以唯一标识一条记录的字段或者字段组合(例如News表)时，需要给表增加一个主键字段，这个增加的主键是无意义的。

　　4、如果找到一个字段可以唯一的标识一条记录，则该表的主键则为这个字段(例如Orders表)，这个主键就是有意义的

　　5、如果找到一个字段组合可以唯一的标识一条记录，则分为以下两种情况

　　6、如果该数据表不需要与其他的表进行数据主-外键关联，则该表的主键则为这个字段组合，这个字段组合的主键也是有意义的

　　7、如果该数据表表需要与其它表产生主-外键关联，这时候也要增加一个主键字段，而把找到的那个字段组合作成唯一索引，原因是多字段主键没法与其它表建立数据关联，这个增加的主键是无意义的。

　　8、无意义的主键类型在自增的int与guid中选择，选择的依据是是否该数据现在或者以后需要进行表分布，需要分布就选择guid，否则就选择自增int，原因是自增的int没法进行表分布