SQL中primary key的作用

保持数据一致性,完整性,主要目的是控制存储在外键表中的数据。 使两张表形成关联,外键只能引用外表中的列的值!

例如:

a b 两个表

a表中存有客户号,客户名称

b表中存有每个客户的订单

有了外键后

你只能在确信b 表中没有客户x的订单后,才可以在a表中删除客户x

建立外键的前提: 本表的列必须与外键类型相同(外键必须是外表主键)。

指定主键关键字: foreign key(列名)

引用外键关键字: references <外键表名>(外键列名)

事件触发限制: on delete和on update , 可设参数cascade(跟随外键改动), restrict(限制外表中的外键改动),set Null(设空值),set Default(设默认值),[默认]no action

例如:

outTable表 主键 id 类型 int

创建含有外键的表:

create table temp(

id int,

name char(20),

foreign key(id) references outTable(id) on delete cascade on update cascade);

说明:把id列 设为外键 参照外表outTable的id列 当外键的值删除 本表中对应的列筛除 当外键的值改变 本表中对应的列值改变。

今天有朋友问我"外键的作用是什么"

 

当朋友问我外键的作用是什么时,我也愣了一下,平常都是在这么用,还没有真正的总结过,外分键的作用呢.下面,我总结了一下外键的作用:

外键 (FK) 是用于建立和加强两个表数据之间的链接的一列或多列。通过将保存表中主键值的一列或多列添加到另一个表中,可创建两个表之间的链接。这个列就成为第二个表的外键。

FOREIGN KEY 约束的主要目的是控制存储在外键表中的数据,但它还可以控制对主键表中数据的修改。例如,如果在 publishers 表中删除一个出版商,而这个出版商的 ID 在 titles 表中记录书的信息时使用了,则这两个表之间关联的完整性将被破坏,titles 表中该出版商的书籍因为与 publishers 表中的数据没有链接而变得孤立了。FOREIGN KEY 约束防止这种情况的发生。如果主键表中数据的更改使之与外键表中数据的链接失效,则这种更改是不能实现的,从而确保了引用完整性。如果试图删除主键表中的行或更改主键值,而该主键值与另一个表的 FOREIGN KEY 约束值相关,则该操作不可实现。若要成功更改或删除 FOREIGN KEY 约束的行,可以先在外键表中删除外键数据或更改外键数据,然后将外键链接到不同的主键数据上去。

外键是用来控制数据库中数据的数据完整性的

就是当你对一个表的数据进行操作

和他有关联的一个或更多表的数据能够同时发生改变

这就是外键的作用

[精] 谈谈外键

外键 (FK) 是用于建立和加强两个表数据之间的链接的一列或多列。通过将保存表中主键值的一列或多列添加到另一个表中,可创建两个表之间的链接。这个列就成为第二个表的外键。

FOREIGN KEY 约束的主要目的是控制存储在外键表中的数据,但它还可以控制对主键表中数据的修改。例如,如果在 publishers 表中删除一个出版商,而这个出版商的 ID 在 titles 表中记录书的信息时使用了,则这两个表之间关联的完整性将被破坏,titles 表中该出版商的书籍因为与 publishers 表中的数据没有链接而变得孤立了。FOREIGN KEY 约束防止这种情况的发生。如果主键表中数据的更改使之与外键表中数据的链接失效,则这种更改是不能实现的,从而确保了引用完整性。如果试图删除主键表中的行或更改主键值,而该主键值与另一个表的 FOREIGN KEY 约束值相关,则该操作不可实现。若要成功更改或删除 FOREIGN KEY 约束的行,可以先在外键表中删除外键数据或更改外键数据,然后将外键链接到不同的主键数据上去。

外键是用来控制数据库中数据的数据完整性的

就是当你对一个表的数据进行操作

和他有关联的一个或更多表的数据能够同时发生改变

这就是外键的作用

 


 

主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。

必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境,就很难对这些键进行修改,所以在开发阶段就设计好主键和外键就是非常必要和值得的。

主键:

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

      1. 惟一地标识一行。

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

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

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

      2. 主键应该是单列的,以便提高连接和筛选操作的效率。

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

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

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

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

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

 


 

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

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

例如有两个表

A(a,b) :a为主键,b为外键(来自于B.b)

B(b,c,d) :b为主键   

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

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

1、外建表达的是参照完整性:这是数据固有的,与程序无关。因此,应该交给DBMS来做。

2、使用外建,简单直观,可以直接在数据模型中体现,无论是设计、维护等回有很大的好处,特别是对于分析现有的数据库的好处时非常明显的--前不久我分析了一个企业现有的数据库,里面的参照完整性约束有的是外键描述,有的是用触发器实现,感觉很明显。当然,文档里可能有,但是也可能不全,但是外键就非常明显和直观。

3、既然我们可以用触发器或程序完成的这个工作(指参照完整性约束),DBMS已经提供了手段,为什么我们要自己去做?而且我们做的应该说没有RDBMS做得好。实际上,早期的RDBMS并没有外键,现在都有了,我认为数据库厂商增加这个功能是有道理的。从这个角度来说,外键更方便。

4、关于方便,根据我带项目的情况来看,程序员确实有反映,主要是在调试时输入数据麻烦:如果数据可以违反参照完整性,那么就是说参照完整性本身就不对名誉业务冲突,此时也不应该用触发期货程序实现;否则,说明数据是错误的,根本就不应该进入数据库!而且,这也应该是测试系统的一个内容:阻止非法数据。实际上,前台程序应该对这种提交失败做出处理。数据是企业的而非程序的,储程序要尽量与数据分离,反之亦然。

最后说一下,建键几个原则:

1、 为关联字段创建外键。

2、 所有的键都必须唯一。

3、避免使用复合键。

4、外键总是关联唯一的键字段。

 外键的作用?  

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

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

例如有两个表

A(a,b) :a为主键,b为外键(来自于B.b)

B(b,c,d) :b为主键   

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

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

1、外建表达的是参照完整性:这是数据固有的,与程序无关。因此,应该交给DBMS来做。

2、使用外建,简单直观,可以直接在数据模型中体现,无论是设计、维护等回有很大的好处,特别是对于分析现有的数据库的好处时非常明显的--前不久我分析了一个企业现有的数据库,里面的参照完整性约束有的是外键描述,有的是用触发器实现,感觉很明显。当然,文档里可能有,但是也可能不全,但是外键就非常明显和直观。

3、既然我们可以用触发器或程序完成的这个工作(指参照完整性约束),DBMS已经提供了手段,为什么我们要自己去做?而且我们做的应该说没有RDBMS做得好。实际上,早期的RDBMS并没有外键,现在都有了,我认为数据库厂商增加这个功能是有道理的。从这个角度来说,外键更方便。

4、关于方便,根据我带项目的情况来看,程序员确实有反映,主要是在调试时输入数据麻烦:如果数据可以违反参照完整性,那么就是说参照完整性本身就不对名誉业务冲突,此时也不应该用触发期货程序实现;否则,说明数据是错误的,根本就不应该进入数据库!而且,这也应该是测试系统的一个内容:阻止非法数据。实际上,前台程序应该对这种提交失败做出处理。数据是企业的而非程序的,储程序要尽量与数据分离,反之亦然。

最后说一下,建键几个原则:

1、 为关联字段创建外键。

2、 所有的键都必须唯一。

3、避免使用复合键。

4、外键总是关联唯一的键字段。


原文出处:http://www.cnblogs.com/8586/archive/2009/03/30/1424967.html

  • 8
    点赞
  • 38
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
### 回答1: 当SQL违反主键约束时,需要采取以下步骤解决: 1. 确定违反主键约束的具体表和列:首先,需要确定哪个表违反了主键约束以及具体是哪一列违反了约束。 2. 检查违反约束的数据:查看违反约束的数据,了解为什么会出现这种情况。可能是由于数据插入、更新或删除操作没有正确地维护主键约束导致的。 3. 修复数据错误:根据具体情况,可以通过更新或删除数据来修复数据错误。如果是插入新数据引发的约束违反,需要确保插入的数据符合主键约束。 4. 检查表设计是否合理:如果主键约束经常被违反,那么可能需要重新审查表的设计。可能需要重新选择合适的主键,或者修改表结构以更好地支持业务需求。 5. 添加或修改约束:如果表没有主键约束,或者已有的主键约束不够严格,可以考虑添加或修改主键约束。确保约束能够正确地唯一标识表的每一行数据。 6. 备份和还原数据库:如果修复数据错误过程可能引发其他问题,建议在进行任何修改之前先备份数据库。这样即使出现意外情况,也可以通过还原数据库来恢复到修复之前的状态。 通过以上步骤,我们可以解决违反主键约束的问题,并确保数据的完整性和一致性。在进行任何修改前,我们需要仔细考虑并验证对数据库操作的影响,以避免引发其他潜在问题。 ### 回答2: 当SQL违反了primary key(主键)约束时,我们可以采取以下几个步骤来解决这个问题: 1. 检查错误消息:首先,我们需要检查SQL数据库返回的错误消息,以了解违反主键约束的具体原因。错误消息通常会提供一些关于违规行的信息,包括主键冲突的列和值。 2. 修改冲突值:一旦我们了解了哪些行违反了主键约束,我们需要修改这些行的值以满足主键的要求。我们可以通过更新或删除冲突行,或者修改主键列的值来完成这一步骤。 3. 更新外键引用:如果主键被其他表的外键引用,则在修改主键值之前,我们需要首先更新涉及到这些行的外键引用。确保在修改主键值之后,所有外键引用仍然有效。 4. 添加缺失主键值:如果主键列的值为空或缺失,我们可能需要为这些行添加新的主键值。这个过程可以通过一个递增的数字、生成一个唯一的GUID(全局唯一标识符)或者使用其他算法来为这些行生成新的主键值。 5. 重新执行SQL操作:一旦我们对冲突行采取了适当的措施,我们可以重新执行原本无法执行的SQL操作。在处理冲突行之后,我们期望不再遇到主键约束违规的问题。 在处理SQL主键约束违规时,我们需要小心并谨慎操作,以确保数据库的完整性和一致性。 ### 回答3: 当SQL语句违反了Primary Key(主键)约束时,我们可以采取以下措施来解决问题: 1. 检查数据插入或更新操作:首先,我们需要仔细检查违反约束的SQL语句,确定是插入操作还是更新操作导致了主键冲突。确认问题后,我们可以针对性地进行处理。 2. 确保主键唯一性:主键的特性就是要求唯一性,因此如果我们要插入的记录已经存在相同的主键值,就会引发约束冲突。我们需要确认待插入的主键值是否与已有的主键值重复,若是,需要进行相应调整,确保主键的唯一性。 3. 修改或删除冲突记录:如果违反主键约束的记录已经存在于数据库,我们需要针对该记录进行修改或删除操作。如果存在错误或重复的记录,可以通过修改其主键值或删除该记录来解决约束冲突。 4. 添加合适的索引:如果主键冲突频繁发生,可能是因为缺乏索引或有错误的索引。我们可以通过添加合适的索引来提高查询效率与唯一性,从而减少主键冲突的发生。 5. 调整数据库设计:如果问题持续存在,可能是数据库设计存在一些问题。我们需要评估数据库的范式化与实体关系,确认是否需要进行适当的修改,以确保主键的唯一性、有效性和一致性。 总之,解决SQL违反Primary Key约束的问题,我们需要仔细分析问题的原因,并采取相应的措施,包括调整数据操作、维护主键唯一性、修改或删除冲突记录、添加索引以及调整数据库设计等。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值