数据库表中主键和外键的含义

主键（Primary

key）：

也称为主码或主关键字，用于惟一地确定一个元组的属性或属性组(复合主码)。每个关系都有一个并且只有一个主码。

外键（Foreign

Key）：也称为外码或外部关键字。如果一个属性集不是所在关系的关键字，但是是其他关系的关键字，则该属性集称为外部关键字。在关系数据库中可以通过外键使两个关系关联，这种联系通常是一对多（1：n）的，其中主（父）关系（1方）称为被参照关系，从（子）关系（n方）称为参照关系。

主键（primary key）是数据库表中对储存数据对象予以唯一和完整标识的数据列或属性的组合。一个数据列只能有一个主键，且主键的取值不能缺失，即不能为空值（Null）。

形象说法：即一个表中某一列或某些列的组合必须是唯一值且不为空。

外键（foreign key）是子表中的列（或某些列的组合）对应于父表的主键列（或某些列的组合）。

形象说法：子表中的列是父表中对应的列的子集。

数据库主键，指的是一个列或多列的组合，其值能唯一地标识表中的每一行，通过它可强制表的实体完整性。

主键可以用来表示一个精确定位的特定的行，如果没有主键，你就无法精准定位一条记录是否就是你要的相关行记录，这样就会导致更新或删除表中特定的行很困难。

而如果我们有主键来约束行记录的唯一性后，就可以利用主键来解决这个问题。

主键的作用:

1）保证实体的完整性;

2）加快数据库的 *** 作速度。

3） 在表中添加新记录时，DBMS会自动检查新记录的主键值，不允许该值与其他记录的主键值重复。

4) DBMS自动按主键值的顺序显示表中的记录。如果没有定义主键，则按输入记录的顺序显示表中的记录。

扩展资料：

主键的必要性

在有些数据库中，虽然主键不是必需的，但最好为每个表都设置一个主键，不管是单主键还是复合主键。它存在代表着表结构的完整性，表的记录必须得有唯一区分的字段，主键主要是用于其他表的外键关联，以及本记录的修改与删除。

主键的无意义性

在开发过程中，可能会看到将一些表使用有意义的字段表示主键，例如“用户登录信息表”将“登录名”（英文名）作为主键，“订单表”中将“订单编号”作为主键，如此设计主键一般都是没什么问题，因为将这些主键基本不具有“意义更改”的可能性。

但是，也有一些例外的情况，例如“订单表”需要支持需求“订单可以作废，并重新生成订单，而且订单号要保持原订单号一致”，那将“订单编号”作为主键就满足不了要求了。因此读者在使用具有实际意义的字段作为主键时，需要考虑是否存在这种可能性。

参考资料：

主键：

关系数据库依赖于主键---它是数据库物理模式的基石。主键在物理层面上只有两个用途：

1

惟一地标识一行。

2

作为一个可以被外键有效引用的对象。

基于以上这两个用途，下面给出了我在设计物理层面的主键时所遵循的一些原则：

1

主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。

2

主键应该是单列的，以便提高连接和筛选 *** 作的效率。

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

3

永远也不要更新主键。实际上，因为主键除了惟一地标识一行之外，再没有其他的用途了，所以也就没有理由去对它更新。如果主键需要更新，则说明主键应对用户无意义的原则被违反了。

注：这项原则对于那些经常需要在数据转换或多数据库合并时进行数据整理的数据并不适用。

4

主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等。

5

主键应当有计算机自动生成。如果由人来对主键的创建进行干预，就会使它带有除了惟一标识一行以外的意义。一旦越过这个界限，就可能产生认为修改主键的动机，这样，这种系统用来链接记录行、管理记录行的关键手段就会落入不了解数据库设计的人的手中。

外键是数据库一级的一个完整性约束，就是数据库基础理论书中所说的“参照完整性”的数据库实现方式。

外键属性当然是可以去掉的，如果你不想再用这种约束，对编程当然不会有什么影响，但相应的录入数据的时候就不对录入的数据进行“参照完整性”检查了。

例如有两个表

A(a,b)

:a为主键，b为外键（来自于Bb)

B(b,c,d)

:b为主键

如果我把字段b的外键属性去掉，对编程没什么影响。

如上面，A中的b要么为空，要么是在B的b中存在的值，有外键的时候，数据库会自动帮你检查A的b是否在B的b中存在。

数据库主键

主键：表中经常有一个列或多列的组合，其值能唯一地标识表中的每一行。这样的一列或多列称为表的主键，通过它可强制表的实体完整性。当创建或更改表时可通过定义 PRIMARY KEY 约束来创建主键。一个表只能有一个 PRIMARY KEY 约束，而且 PRIMARY KEY 约束中的列不能接受空值。由于 PRIMARY KEY 约束确保唯一数据，所以经常用来定义标识列。

作用:

1）保证实体的完整性;

2）加快数据库的 *** 作速度

3） 在表中添加新记录时，ACCESS会自动检查新记录的主键值，不允许该值与其他记录的主键值重复。

4) ACCESS自动按主键值的顺序显示表中的记录。如果没有定义主键，则按输入记录的顺序显示表中的记录。

在有些数据库中，虽然主键不是必需的，但最好为每个表都设置一个主键，不管是单主键还是复合主键。它存在代表着表结构的完整性，表的记录必须得有唯一区分的字段，主键主要是用于其他表的外键关联，以及本记录的修改与删除。

主键的无意义性

在开发过程中，读者可能会看到将一些表使用有意义的字段表示主键，例如“用户登录信息表”将“登录名”（英文名）作为主键，“订单表”中将“订单编号”作为主键，如此设计主键一般都是没什么问题，因为将这些主键基本不具有“意义更改”的可能性。但是，也有一些例外的情况，例如“订单表”需要支持需求“订单可以作废，并重新生成订单，而且订单号要保持原订单号一致”，那将“订单编号”作为主键就满足不了要求了。因此读者在使用具有实际意义的字段作为主键时，需要考虑是否存在这种可能性。

主键的选择

①编号作主键

此方法就是采用实际业务中的唯一字段的“编号”作为主键设计，这在小型的项目中是推荐这样做的，因为这可以使项目比较简单化，但在使用中却可能带来一些麻烦，比如要进行“编号修改”时，可能要涉及到很多相关联的其他表，就像黎叔说的“后果很严重”;还有就是上面提到的“业务要求允许编号重复时”，我们再那么先知，都无法知道业务将会修改成什么

②自动编号主键

这种方法也是很多朋友在使用的，就是新建一个ID字段，自动增长，非常方便也满足主键的原则，优点是：数据库自动编号，速度快，而且是增量增长，聚集型主键按顺序存放，对于检索非常有利;数字型的，占用空间小，易排序，在程序中传递也方便;如果通过非系统增加记录（比如手动录入，或是用其他工具直接在表里插入新记录，或老系统数据导入）时，非常方便，不用担心主键重复问题。

缺点：其实缺点也就是来自其优点，就是因为自动增长，在手动要插入指定ID的记录时会显得麻烦，尤其是当系统与其他系统集成时，需要数据导入时，很难保证原系统的ID不发生主键冲突（前提是老系统也是数字型的）;如果其他系统主键不是数字型那就麻烦更大了，会导致修改主键数据类型了，这也会导致其他相关表的修改，后果同样很严重;就算其他系统也是数字型的，在导入时，为了区分新老数据，可能想在老数据主键前统一加一个“o”(old)来表示这是老数据，那么自动增长的数字型又面临一个挑战。

主键:唯一标识表中的所有行的一个列或一组列主键不允许空值不能存在具有相同的主键值的两个行因此主键值总是唯一标识单个行表中可以有不止一个键唯一标识行每个键都称作候选键只有一个候选键可以选作表的主键所有其它候选键称作备用键尽管表不要求具有主键但定义主键是很好的做法 在规范化的表中每行中的所有数据值都完全依赖于主键例如在以 EmployeeID 作为主键的规范化的 employee 表中所有列都应包含与某个特定职员相关的数据该表不具有 DepartmentName 列因为部门的名称依赖于部门 ID而不是职员 ID

以上就是关于数据库表中主键和外键的含义全部的内容，包括:数据库表中主键和外键的含义、数据库的主键是怎么回事、数据库中为何要设置主键呢有什么作用等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！