数据库设计之外键的思考

关于是否使用外键在业界也没有统一的标准,大家争论的焦点是数据一致性和性能上。

支持使用外键方,强调如果不使用外键,数据一致性无法保证,性能消耗可以忽略。

反对使用外键方,数据一致性可以通过程序保证,性能有大问题,数据维护很麻烦,如果是大系统,整个外键的关系就像编制的一张大网。再者开发人员很难真正用好外键。

其实两种观点我都支持,现状是我基本没用过外键。没使用外键会出现什么问题呢?

1.数据一致性无法保证。出现这种情况最多的情况是,如A表示基础表,它被很多模块引用,B表是业务表,A表中删除了数据,B表的数据关联A的信息没有删除,导致写SQL时会出现大量的外连接。

2.从表上没有建索引。如果从表上有外键,这种情况悲剧就要发生了。请看参考我之前写的 外键不加索引引起的性能问题

3.使用外键在后台修改数据非常麻烦,当然这个不是外键的问题,只是系统自身的问题。

   你看任何一本涉及到数据库设计的书籍,都会告诉你一定要使用外键,但理想和实现总是有点差距,如何选择,我的建议:

1.如果你对数据一致性要求非常高,关乎人命,钱,一定要加外键,像财务系统等。反之,可以牺牲一下,换取方便。

2.如果不加外键,基础的表(就是会被引用的表)要做逻辑删除(加一个删除的标识位),可以避免大量的外连接。

3.不管是否加外键,一定要索引。

时间: 2024-11-07 09:52:06

数据库设计之外键的思考的相关文章

一个微博数据库设计带来的简单思考

http://www.blogjava.net/kalman03/archive/2010/07/19/326558.html 在微博系统中,当前用户.关注者(也就是粉丝).被关注者(崇拜对象)这三种角色是少不了的.他们之间看似简单的关系,但是其中数据库表将如何设计,却让我很难琢磨,在如下解决方案中,你们会选择哪种?为什么要选择这种?是否有更好的解决方案? 解决方案一: 表名 用户信息表 字段名 字段代码 字段类型 描述 用户名 User_id Varchar(20) 主键 登陆密码 Passw

数据库设计杂谈

注:本人开发经验尚浅,下文主要谈的是自己的一些想法,不足之处请指出. 最近半年时间都花在管理系统的开放上面,对数据库的设计有一些自己的想法,在我看来数据库设计的key point就是妥协.一个设计的比较好的数据库都是在业务逻辑.设计规约和便于开发这三者之前来回考量,从而获得3-win的结果.下面主要是在思考和总结的点. 如何设计出高灵活性的数据库 可以说在项目交付前,需求不断在变,如何在需求改变的同时尽可能减少对表结构的修改是我现在考虑的问题.对于一般情况而言,在设计的时候我们可以适当添加一些预

手势识别项目小组——数据库设计心得

因为我们的项目是算法类,所以项目本身的需求不太明确.设计数据库的过程其实本身也是在进一步明确需求的过程. 这是我们画出的用例图: 以下是我们小组成员的数据库设计心得: JJ: 通过本次数据库设计的过程,我经历了很多也学会了很多. 首先因为课程组的要求是设计出至少15张表,而我们想要达到15张表是很困难的.我们的设计想法是先根据我们之前设计的原型先设计出一些表,根据登陆.注册.历史记录等设计了几张表.但是这些表也基本是基于用户而设计的,后来我们也寻求了指导老师的帮助,指导老师帮忙想了一个损失函数表

逻辑数据库设计 - 需要ID(谈主键Id)

本文的目标就是要确认那些使用了主键,却混淆了主键的本质而造成的一种反模式. 一.确立主键规范 每个了解数据库设计的人都知道,主键对于一张表来说是一个很重要,甚至必需的部分.这确实是事实,主键是好的数据库设计的一部分.主键是数据库确保数据行在整张表唯一性的保障.它是定位到一条记录并且确保不会重复存储的逻辑机制.主键也同时可以被外键引用来建立表与表之间的关系. 难点是选择那一列作为主键.大多数表中的每个属性值都有可能被很多行使用.例如姓名,电子邮件地址等等都不能保证不会重复. 在这样的表中,需要引入

mysq数据库设计(主键与外键)

主键可以是真实实体的属性,但是常用的好的解决方案是,利用一个与实体信息不相关的属性,作为唯一标示(加个id字段)主键与业务逻辑不发生关系,只用来标示记录 可以在定义完字段后,再定义多列主键(组合主键) 例:primary key(id,name,age);(不是说3个字段都是主键,因为一个表只能有一个主键,可以是3个字段组合成的主键) 设计: 两个实体表内,存在相同的主键字段 如果记录的主键值等于另一个关系表内记录的主键则两天记录对应 1:1对应  数据库设计的时候(常用的信息和不常用的信息分开

数据库设计中主键问题

转自: http://www.jb51.net/article/40933.htm 数据库主键在数据库中占有重要地位.主键的选取策略决定了系统是否可靠.易用.高效.本文探讨了数据库设计过程当中常见的主键选取策略,并剖析了其做主键的优缺点,提出了相应的解决问题的方法 在基于关系型数据库设计时候,通常要为每张表指定一个主键,所谓主键就是能够唯一标识表中某一行记录的属性或属性组,一个表只能有一个主键,但可以有多个候选索引.因为主键可以唯一标识某一行记录,所以可以确保执行数据更新.删除.修改时不出现错误

数据库设计中主键字段类型的选择

很久都没有写过博客了,从最后一次发表的文章到现在已经是两个多月的时间了,一直都想写点什么,可一直没有时间(其实都是借口),随笔内容无疑就是工作学习中的总结,经验的分享,也是自己成长的一面镜子,好了,言规正传,这次谈谈在数据库设计中主键字段类型的选择. 做web 开发时,经常要与数据库交互,数据库主键的选择也犹为重要,怎么么选择数据库主键字段的类型,主要从以下几个方面考虑: 1. 首先要符合业务需求,这是设计中重要的出发点 2. 数据库的迁移问题,考虑在后期是否要经常迁移,数据库高度唯一性 3.程

数据库设计---关于建表的时候选择横标和竖表(纵表)的一点思考

本文出处:http://www.cnblogs.com/wy123/p/6677073.html 在做数据统计类数据库设计的时候,在考虑数据存储的时候,经常会遇到逻辑上同一个BusinessID对应多个数据点的情况,比如工资表中的员工ID以及各项工资信息,财务表中的各个报表Id和多个数据点之间的信息面对这种情况,如何来设计表结构,是横表,还是竖表,各有那些优缺点,本文将做一个粗浅的分析. 横标和竖表的表现形式 日常生活中也有很多类似的例子,先用一个Excel画一个例子,比如工资表这么做就是“横表

逻辑数据库设计 - 无视约束(谈外键)

有一些开发人员不推荐使用完整性约束,你可能听过以下这么几点不使用外键的原因. 1.数据更新有可能和约束冲突. 2.当前的数据库设计如此灵活,以致于不支持引用完整性约束. 3.数据库为外键建立的索引会影响性能. 4.当前使用的数据库不支持外键. 5.定义外键的语法并不简单,还需要查阅. 一.反模式:无视约束 即使第一感觉告诉你,省略外键约束能使得数据库设计更加简单.灵活,或者执行更加高效,你还是不得不在其他方面付出相应的代价 -- 必须增加额外的代码来手动维护引用完整性. 1.完整性问题 很多人对