在实体关系模型中，我们知道有三种关系：一对一、一对多、多对多。这只是概念上的关系，但是在真实的关系数据库中，我们只有外键，并没有这三种关系，那么我们就来说一说在关系数据库管理系统中，怎么实现这三种关系。
一对多
这里先讲解一对多，因为这个关系最简单。一对多和多对一是一回事，所以就不再提多对一这个词。一对多的概念是一个对象A会对应多个对象B，而从B的角度看，一个对象B只会对于一个对象A。比如说班级和学生就是一对多关系。一个班级对应多个学生，一个学生只会对于一个班级。
一对多的关系之所以说简单，是因为RDBMS的【外键】其实就是表示一对多关系。对于一对多关系，我们只需要在“多”的这个表中建立“一”的外键关联即可，而“一”这边的表不需要做任何修改。比如前面说到的班级学生关系。班级表不变，学生表增加班级Id作为外键。
多对多
多对多的关系在数据库设计时比一对一要常见，所以这里先说说多对多。多对多是一个对象A对应多个对象B，从B角度看，一个对象B也会对应多个对象A。比如说学生和课程的关系就是多对多关系。一个学生会学习多门课程，一门课程会有多个学生来选修。
在RDBMS中，必须使用中间表来表示多对多的关系。中间表我们可以分成两种，一种是纯粹表示关系的中间表，一种是表示中间实体的中间表。
纯粹表示关系的中间表很简单，只需要两列：AID和BID，AID以外键关联到A表的主键，BID以外键关联到B表的主键，然后这两个列组成联合主键。这个中间表纯粹是表示多对多关系而存在，在业务上不会有对应的实体与之对应。比如前面提到的学生和课程的关系，如果我们只需要知道哪些学生上哪些课，哪些课有哪些学生选，不需要有更多的信息的情况下，我们就可以建立“学生课程”中间表，里面只有学生ID和课程ID两个字段。
中间实体是在纯粹的中间关系表的基础上，加上了更多的属性，从而形成了一个新的实体。比如前面提到的学生和课程的关系，如果我们需要记录学生选课的时间、学生选择这门课程后的考试成绩，那么我们就像建立一个“选课”实体，该实体具有如下属性：
选课ID，主键
学生ID，与学生表做外键关联
课程ID，与课程表做外键关联
选课时间，DateTime类型
考试成绩，记录选修该课程后考试的最终成绩
这就是一个中间实体，已经完全脱离了普通的多对多关系中间表，而变成一个实体的形式的存在，所以按照前面博客中讲到的主键设计的原则，我们可以单独建立一个选课ID的列作为数据库的主键，该主键本身并没有业务含义。
一对一
一对一概念上是说一个对象A最多对应一个对象B，从B角度看，也是一个对象B最多对应一个对象A。比如说班主任（教师）和班级的关系，一个班主任最多管理一个班级，一个班级也最多只有一个班主任。
一对一的关系在数据库设计中，是使用的最少的关系，因为一般来说，如果两个实体是一对多关系，那么我们也可以把这两个实体合并成一个实体。但是在设计中，我们仍然会遇到两个完全不同的实体，之间存在一对一关系。
一对一的RDBMS实现是在其中的一个表上建立外键指向另一个表，同时在该外键列上建立唯一约束。比如前面说到的班主任和班级关系，我们可以在班级表建立班主任字段，然后再在该字段建立唯一约束。因为每个班都会有班主任，所以班主任字段是不允许为空的。一个教师可以当某个班的班主任，也可以不当任和班的班主任，同时也不可能在班级表的班主任字段上出现两次，所以最多就当一个班的班主任，所以该设计满足需求。
那么我们可不可以反过来，在教师表中建立所管理的班级Id字段，指向班级表，并建立唯一约束呢？除了不满足“每个班必然有一个班主任”这个业务约束外，其他都没有问题。所以如果对于一对一的情况，如果那边必须要求持有另一边，则就在哪边增加外键字段；如果没有要求必须持有一个另一类实体的话，就哪边添加外键列都行。
外键与索引
外键：如果一个表中的若干个字段是来自另外若干个表的主键，则这若干个字段就是外键。外键并没有强制一定来自其他另外的表，也可能来自本表的主键。含有外键的表通常叫做外建表，外键字段来自【参考】的那个表则叫做主键表。
外键是一种约束，与索引的概念不一样，只是大多数情况下，我们建立外键时，都会在外键列上建立对应的索引。外键的存在会在每一次数据插入、修改时进行约束检查，如果不满足外键约束，则禁止数据的插入或修改，这必然带来一个问题，就是在数据量特别大的情况下，每一次约束检查必然导致性能的下降。索引其实也有类似的问题，索引如果建多了，那么在插入删除修改数据时也要去维护对应的索引，所以索引的存在也会导致数据操作变慢。
不过外键与索引的优点不同，外键只是保证数据的一致性，并不能给系统性能带来任何好处，所以由于外键导致的插入数据变慢会随着数据量的增长而越来越严重。而索引的目的是为了检索数据更快，维护数据时导致的索引数据的变更，对性能的影响不会像外键那样随着数据量增长而变得严重（当然大数量时的索引树维护会比小数据量的索引树维护更麻烦，但至少不是像外键那样）。
出于性能的考虑，如果我们的系统完全由我们开发的程序使用，而不需要提供数据库给其他应用系统写入数据，而且对性能要求较高，那么我们可以考虑在生产环境中不使用外键，只需要建立能够提高性能的索引。由于整个数据库的操作都是由我们开发的程序来完成的，所以我们程序可以在开发过程中做好各方面的一致性检查，保证操作的数据是满足外键约束的，而不需要真正的存在这样一个外键约束。怎么做到这一点呢，首先，我们在建立数据库时有多个脚本，包括创建表、创建初始化数据、创建索引、创建外键等，我们在开发和测试环境中，都把这些脚本运行了，以使开发测试环境中的数据库是完整的，经过大量测试保证应用程序能够维护数据之间的约束的情况下，那么我们在生产时，并不需要运行创建外键这个脚本文件，只需要创建表、初始化数据、创建索引等即可。
在数据库设计时，主要就是对实体和关系的设计，实体表现出来就是表，关系表现出来就是外键。而对于一个表，由两部分组成：主键和属性。主键的简单定义就是表中为每一行数据的唯一标识。其实更准确的说法，每一行数据的唯一标识是候选键（Candidate Key），一个表中可以有很多个候选键，主键是候选键中的一个，主要用于更方便的检索和管理数据。一个表中可以有多个候选键，但是只有一个主键。由于主键常常用于检索数据，也用于表之间的关联，所以主键的设计的好坏将会严重影响数据操作的性能。下面来介绍下主键设计的几个考虑因素。
主键的数据类型
最常见的主键数据类型是数字类型、固定长度的字符类型和GUID类型。通常情况下，RDBMS会在主键上建立聚集索引（SQL Server默认都这么做），由于我们使用B-Tree的数据结构来存储索引数据，所以一般对主键有以下两个要求：
越短越好——越短在一个Page中存储的节点越多，检索速度就越快。
顺序增长——如果每一条插入的数据的主键都比前面的主键大，那么B-Tree上的节点也是顺序增长的，不会造成频繁的B-Tree分割。
越短越好是为了查询的速度快，顺序增长是为了插入速度快。
有了这两个要求，我们再来分析下各个数据类型：
数字类型：根据数据量决定是用Int16还是Int32或者Int64，能用Int32的就不需要使用Int64。
字符类型：基本不满足前面提到的2点要求，字符类型一般不会很短，而且也很可能不是顺序增长的，所以不是特别推荐的主键类型。当然如果确实业务需求使用字符类型，那么也尽量使用char(XX)而不要使用varchar(XX)，因为在RDBMS中，对于定长字符串和变成字符串的数据结构和处理是不一样的，varchar的性能更差。
GUID类型：这个类型并不是所有数据库都有对应的数据类型，SQL Server有uniqueidentifier，MySQL没有。GUID类型在SQL Server中是16个字节，不算短，比4个字节的Int32长多了。在插入新数据时，GUID一般都是使用NewId()这样的生成随机GUID的方式生成的，所以也不是顺序增长的，在插入速度上不会很快。
通过上面的比较，我们知道使用【数字类型】是更好的方式，那么我们为什么还会有人使用GUID和字符串来当主键呢？那是因为：
相对于数字类型，字符类型更易读易记，在检索关联的数据时，更方便直接。
GUID的优势是全球唯一，也就是说同样的系统，如果部署了多套环境，那么里面的数据的主键仍然是唯一的，这样有助于数据的集成。典型的例子就是一个系统在全国每个省份都部署一套，每个省份的数据各种录入，互不干扰，然后再把每个省的数据集成起来为总部做分析。
最佳实践：
主键通常都是整数，不建议使用字符串当主键（如果主键是用于集群式服务，可以采用字符串类型）
主键的值通常都不允许修改，除非本记录被删除。
主键的值通常不重用，意味着记录被删除后，该主键值不再使用。
主键不要直接定义成【id】，而要加上前缀，定义成【表名id】或者【表名_id】
要用代理主键，不要使用业务主键
任何一张表，强烈建议不要使用有业务含义的字段充当主键
我们通常都是在表中单独添加一个整型的编号充当主键字段
数据库主键与业务主键
前面说到一个表可能有很多个唯一标识的候选键，那么这么多候选键中，哪个应该拿来做主键呢？一种方案是再新建一个独立的字段作为主键，该字段并没有业务含义，只是一个自增列或者流水号，用于唯一标识每一行数据，这是数据库主键。另外一种方案是选择其中较短较常用的属性作为主键，这是业务主键。个人建议是不要使用任何有业务含义的字段作主键，而是使用一个自增的（或者系统生成的）没有实际业务意义的字段作为主键。为什么呢？主要是出于以下考虑：
具有业务意义的字段很可能是用户从系统录入的，不要信任用户的任何输入，只要是用户自己录入的，那么就很有可能录错了，如果发现录入错误，这个时候再对主键进行修改，将会涉及到大量关联的外键表的修改，是很麻烦的一件事情。比如在做人员表的时候，就不要使用员工号或者身份证号做主键。
具有业务意义的字段虽然在当前阶段是唯一的，是不变的，但是并不能保证随着公司政策变动、业务调整等原因，导致该业务字段需要修改，以满足新的业务要求，这个时候要修改主键也是很麻烦的事情。比如部门表，我们以部门Code作为主键，但是后来部门变动，Code修改，则系统部门表的主键也得更改。
还有一个原因是业务主键在数据录入的时候不一定是明确知道的，有时我们会在不知道业务主键的情况下，就录入其他相关信息，这个时候，如果使用业务主键做数据库的主键，那么数据将无法录入。比如员工表把员工号作为主键，那么员工还没有入职，没有员工号的时候，HR需要先维护一些该预入职员工的信息是不可能的。
联合主键
联合主键就是以多个字段来唯一标识每一行数据。前面已经说到主键应该越短越好，而且是建议是一个没有意义的自增列，那么是不是就不会再需要联合主键呢？答案是否定的，我们仍然可能会使用到联合主键。联合主键主要使用在多对多的关系时，中间表就需要使用联合主键。在简单的多对多关系中，我们不需要为中间的关联建立实体，所以中间表可能就只需要两列，分别是两个实体表的主键。
主键值的生成
主键值的生成可以参考NHibernate的配置，概况下来主要有这么几种生成方式：
自增，这是SQL Server常用的主键生成方式，完全由数据库管理主键的值。
Sequence对象，这是Oracle常用的主键生成方式，现在SQL Server已支持。主要是在数据库中有一个Sequence对象，通过该对象生成主键。
GUID，这是用于GUID类型的主键，可以使用newid()这种数据库提供的函数，或者使用程序生成Guid并赋值。
Hilo值，这是一种使用高低位算法生成的数字值的主键。该值由NHibernate程序内部生成。
其他程序赋值，完全由程序根据自己的算法生成并赋值。
更详细的主键生成，我们可以参见：http://www.cnblogs.com/chenkai/archive/2009/04/13/1434912.html
主键与索引
在概念和作用上，主键与索引是完全两个不同的东西，但是由于我们大部分情况下都是使用主键检索数据，所以大部分数据库的默认实现，在建立主键时会自动建立对应的索引。
以SQL Server为例，默认情况下，建立主键的列，就会建立聚集索引，但是实际上，我们可以在建立主键时不使用聚集索引。另外还有一个唯一约束（索引）的概念，该索引中的数据必须是唯一不能重复的，感觉和主键的意义一样，但是还是有一点点区别。
主键是只能由一个，而唯一约束（索引）在一个表中可以有多个。
主键不能为空，而唯一约束（索引）是可以为空的。
主键表和外键表删除问题？
先删除主键表还是外键表呢？
先删除外键表，在删除主键表。先删除主键表，会报错，因为这会导致外键表中的数据引用失败。
本文出自 “Share your knowledge” 博客，请务必保留此出处http://skypegnu1.blog.51cto.com/8991766/1668871
原文地址：http://skypegnu1.blog.51cto.com/8991766/1668871
