三国演义 三国演义是一部在华人世界非常普及的历史小说,是由罗贯中根据元朝的三国志平话改编,他以东汉末年魏、蜀、吴三国斗争为主题,收集历史资料和说书人的故事,成为这一部大家都非常熟悉的故事。 或许我们现在觉得这些历史已经跟我们没什么关系了,不过大家都知道关公过五关斩六将,刘备三顾茅芦,诸葛孔明的空城记。 这些老掉牙的故事,总是不断的出现在电影、电视剧和各种平台的游戏,一代又一代的传承下去。 这应该是因为三国演义的确是一个好故事,很多很精采的好故事,就像美国畅销作家史帝芬金所说的,一个好故事是不会寂寞的。 三国演义的普及,让人认为里面讲的故事其实就是真的历史,罗贯中在编这本书的时候,大概是为了让它可以比较戏剧化一些,采用了很多当时说书人的内容,这些内容是在民间流传或由说书人编造的,跟历史并不一样。 例如大家熟悉的关公斩华雄,在三国演义中是一段非常的精采故事,作者使用很短的内容让关云长的豪勇,简单、清楚而且非常震憾的呈现给读者。 不过根据史料的考证,其实华雄的头是被孙坚砍掉的。 这也是为什么清朝的时候就有人评论三国演义是「七实三虚,惑乱观者」。…
Mysql: 外键约束, CASCADE、SET NULL、RESTRICT、NO ACTION分析和作用, Cannot delete or update a parent row: a foreign key constraint fails
MySQL有两种常用的引擎类型:MyISAM和InnoDB。目前只有InnoDB引擎类型支持外键约束。InnoDB中外键约束定义的语法如下:
ALTER TABLE tbl_name ADD [CONSTRAINT [symbol]] FOREIGN KEY [index_name] (index_col_name, ...) REFERENCES tbl_name (index_col_name,...) [ON DELETE reference_option] [ON UPDATE reference_option]
例如:
ALTER TABLE `user_resource` CONSTRAINT `FKEEAF1E02D82D57F9` FOREIGN KEY (`user_Id`) REFERENCES `sys_user` (`Id`)
InnoDB也支持使用ALTER TABLE来删除外键:
ALTER TABLE `user_resource` DROP FOREIGN KEY `FKEEAF1E02D82D57F9`;
外键的使用需要满足下列的条件:
1. 两张表必须都是InnoDB表,并且它们没有临时表。
2. 建立外键关系的对应列必须具有相似的InnoDB内部数据类型。
3. 建立外键关系的对应列必须建立了索引。
4. 假如显式的给出了CONSTRAINT symbol,那symbol在数据库中必须是唯一的。假如没有显式的给出,InnoDB会自动的创建。
如果子表试图创建一个在父表中不存在的外键值,InnoDB会拒绝任何INSERT或UPDATE操作。如果父表试图UPDATE或者DELETE任何子 表中存在或匹配的外键值,最终动作取决于外键约束定义中的ON UPDATE和ON DELETE选项。InnoDB支持5种不同的动作,如果没有指定ON DELETE或者ON UPDATE,默认的动作为RESTRICT:
1. CASCADE: 从父表中删除或更新对应的行,同时自动的删除或更新自表中匹配的行。ON DELETE CANSCADE和ON UPDATE CANSCADE都被InnoDB所支持。
2. SET NULL: 从父表中删除或更新对应的行,同时将子表中的外键列设为空。注意,这些在外键列没有被设为NOT NULL时才有效。ON DELETE SET NULL和ON UPDATE SET SET NULL都被InnoDB所支持。
3. NO ACTION: InnoDB拒绝删除或者更新父表。
4. RESTRICT: 拒绝删除或者更新父表。指定RESTRICT(或者NO ACTION)和忽略ON DELETE或者ON UPDATE选项的效果是一样的。
5. SET DEFAULT: InnoDB目前不支持。
NULL、RESTRICT、NO ACTION
删除:从表记录不存在时,主表才可以删除。删除从表,主表不变
更新:从表记录不存在时,主表才可以更新。更新从表,主表不变
CASCADE
删除:删除主表时自动删除从表。删除从表,主表不变
更新:更新主表时自动更新从表。更新从表,主表不变
SET NULL
删除:删除主表时自动更新从表值为NULL。删除从表,主表不变
更新:更新主表时自动更新从表值为NULL。更新从表,主表不变
外键约束使用最多的两种情况无外乎:
1)父表更新时子表也更新,父表删除时如果子表有匹配的项,删除失败;
2)父表更新时子表也更新,父表删除时子表匹配的项也删除。
前一种情况,在外键定义中,我们使用ON UPDATE CASCADE ON DELETE RESTRICT;后一种情况,可以使用ON UPDATE CASCADE ON DELETE CASCADE。
InnoDB允许你使用ALTER TABLE在一个已经存在的表上增加一个新的外键:
ALTER TABLE tbl_name ADD [CONSTRAINT [symbol]] FOREIGN KEY [index_name] (index_col_name, ...) REFERENCES tbl_name (index_col_name,...) [ON DELETE reference_option] [ON UPDATE reference_option]
InnoDB也支持使用ALTER TABLE来删除外键:
ALTER TABLE tbl_name DROP FOREIGN KEY fk_symbol;
外键是否采用看业务应用场景,以及开发成本的,大致列下什么时候适合,什么时候不适合使用:
1. 互联网行业应用不推荐使用外键: 用户量大,并发度高,为此数据库服务器很容易成为性能瓶颈,尤其受IO能力限制,且不能轻易地水平扩展;若是把数据一致性的控制放到事务中,也即让应用服务器承担此部分的压力,而引用服务器一般都是可以做到轻松地水平的伸缩;
2.传统行业
1>.软件应用的人数有限,换句话说是可控的;
2>.数据库服务器的数据量也一般不会超大,且活跃数据有限;
综合上述2句话描述,也即数据库服务器的性能不是问题,所以不用过多考虑性能的问题;另外,使用外键可以降低开发成本,借助数据库产品自身的触发器可以实现表与关联表之间的数据一致性和更新;最后一点,使用外键的方式,还可以做到开发人员和数据库设计人员的分工,可以为程序员承担更多的工作量;
为何说外键有性能问题:
1.数据库需要维护外键的内部管理;
2.外键等于把数据的一致性事务实现,全部交给数据库服务器完成;
3.有了外键,当做一些涉及外键字段的增,删,更新操作之后,需要触发相关操作去检查,而不得不消耗资源;
4.外键还会因为需要请求对其他表内部加锁而容易出现死锁情况;