34,499
社区成员
发帖
与我相关
我的任务
分享散点分，大家来讨论一个优化问题，欢迎参与
对于数据库关系（主外键）的设计，不外乎几种
第一种是层层关联，相关的数据只存储一份，这样在增加修改时数据量少，但在查询时必然得通过视图或程序取出相同数据，此种方式，强调数据间的连系紧密性，优点很明白，就是能减少存储量，减少数据的不一致性，不会出现同一个编号的东西，在某一环节叫A，另一环节叫B的情况，但可能出现要取一个完整的数据信息时，需要多层反推，或者是视图内嵌视图的情况，
第二种是遍地开发，把数据复制到多个表中，程序可能变更复杂些，但每个表里的每条记录都是完整或基本完整的，这样在列示或查看时，可以显著地减少工作量，但由此带来的为了保证数据同步而增加了系统开销，如修改基本数据时，相关联的表，可能名称也要同时UPDATE
第三中，两种结合形，优势互补，也不失为中庸之道
个人认为：这两种方法都无可厚非，关系看应用的不同，如果WEB上，现在一些论坛，select操作的量可能要占到80%或更多，这时，似乎应该选用第2种更实际些，
但一些商用MIS系统，却经常让数据库设计显得很为难，不知如何取舍，
在这里，小弟抛臭砖一块，期待能引出大家之美玉，谈谈想法，比如各在系统设计时如何考虑，实施后碰到的问题，以及根据哪些应用进行取舍？
第一种是层层关联，相关的数据只存储一份，这样在增加修改时数据量少，但在查询时必然得通过视图或程序取出相同数据，此种方式，强调数据间的连系紧密性，优点很明白，就是能减少存储量，减少数据的不一致性，不会出现同一个编号的东西，在某一环节叫A，另一环节叫B的情况，但可能出现要取一个完整的数据信息时，需要多层反推，或者是视图内嵌视图的情况，
第二种是遍地开发，把数据复制到多个表中，程序可能变更复杂些，但每个表里的每条记录都是完整或基本完整的，这样在列示或查看时，可以显著地减少工作量，但由此带来的为了保证数据同步而增加了系统开销，如修改基本数据时，相关联的表，可能名称也要同时UPDATE
第三中，两种结合形，优势互补，也不失为中庸之道
个人认为：这两种方法都无可厚非，关系看应用的不同，如果WEB上，现在一些论坛，select操作的量可能要占到80%或更多，这时，似乎应该选用第2种更实际些，
但一些商用MIS系统，却经常让数据库设计显得很为难，不知如何取舍，
在这里，小弟抛臭砖一块，期待能引出大家之美玉，谈谈想法，比如各在系统设计时如何考虑，实施后碰到的问题，以及根据哪些应用进行取舍？
...全文
请发表友善的回复…
发表回复
Rotaxe 2003-11-24
- 打赏
- 举报
我觉得不一定要完全规范化，同意pbsql(风云)。
8LY8Apollo 2003-11-24
- 打赏
- 举报
up
lczddd 2003-11-24
- 打赏
- 举报
呵呵，不能定的太死，具体情况具体分析了。。
swich 2003-11-24
- 打赏
- 举报
第一种
Benimarunikado 2003-11-24
- 打赏
- 举报
既然是讨论，检讨就不必了～
我的看法是：
RDBMS的一个显著特点就是尽可能的减少数据冗余，为什么呢？数据冗余问题是数据库的一大克星：浪费存储空间，极容易造成数据不一致，给数据的修改和维护增加了极大的开销；另外还可能带来“脏数据”（无效数据或不正确的数据）；
因此，我极力赞成楼主的第一个方案！虽然可能会在建立数据库时麻烦一些（关联，嵌套过多），但是在数据库建立好了之后会带来很多便利！
/* 个人观点！ */
我的看法是：
RDBMS的一个显著特点就是尽可能的减少数据冗余，为什么呢？数据冗余问题是数据库的一大克星：浪费存储空间，极容易造成数据不一致，给数据的修改和维护增加了极大的开销；另外还可能带来“脏数据”（无效数据或不正确的数据）；
因此，我极力赞成楼主的第一个方案！虽然可能会在建立数据库时麻烦一些（关联，嵌套过多），但是在数据库建立好了之后会带来很多便利！
/* 个人观点！ */
qianduo 2003-11-24
- 打赏
- 举报
第一种办法
voyager 2003-11-24
- 打赏
- 举报
应该是我自己说得不够明白，确切的说，本贴本意是作一个调查，并且要求对你的投票作出详细的解释：）是我自己错了，刚接到一个贴友的电话，这里检讨一下
voyager 2003-11-24
- 打赏
- 举报
希望大家从实例的角度评说优缺点，以及实施中碰到的问题，而不是从书上抄一段什么是外键，什么是范式的，这些，我想作过数据库设计的都会懂一些
jingxijun 2003-11-24
- 打赏
- 举报
学习
pbsql 2003-11-24
- 打赏
- 举报
其实主要还是取决于你的系统是插入更新数据多还是查询多，若数据经常插入更新则选一，否则可以考虑二、三
pbsql 2003-11-24
- 打赏
- 举报
第一种只在查询时会降低系统性能，插入更新时都会很快
第二、三种可以通过触发器保证数据一致性，但每次插入更新时都会触发从而降低系统性能
所以建议第一种
第二、三种可以通过触发器保证数据一致性，但每次插入更新时都会触发从而降低系统性能
所以建议第一种
yoobj 2003-11-24
- 打赏
- 举报
当然是第一种办法
zjcxc 元老 2003-11-24
- 打赏
- 举报
毕竟,复杂的关系用存储过程和视图来处理.
要不,也就叫关系型数据库了.
要不,也就叫关系型数据库了.
zjcxc 元老 2003-11-24
- 打赏
- 举报
我个人怎么都建议选择第一种
pengdali 2003-11-24
- 打赏
- 举报
帮助上都有，你如果是程序员，应该可以自己找到的。
pengdali 2003-11-24
- 打赏
- 举报
转贴就不贴了。怕太多了，刷屏。
在系统设计时我还是认为按你说的第一点。你完全可以用视图、索引视图、参数视图。
在系统设计时我还是认为按你说的第一点。你完全可以用视图、索引视图、参数视图。
txlicenhe 2003-11-24
- 打赏
- 举报
当然是第一种办法
txlicenhe 2003-11-24
- 打赏
- 举报
1:
数据库设计专题：
http://www.csdn.net/subject/251/
2:
看看你的设计是不是满足第三范式3NF .
范式
构造数据库必须遵循一定的规则在关系数据库中这种规则就是范式范式是符合
某一种级别的关系模式的集合关系数据库中的关系必须满足一定的要求即满足不同的
范式目前关系数据库有六种范式第一范式1NF 第二范式2NF 第三范式3NF
第四范式4NF 第五范式5NF 和第六范式6NF 满足最低要求的范式是第一
范式1NF 在第一范式的基础上进一步满足更多要求的称为第二范式2NF 其余
范式以次类推一般说来数据库只需满足第三范式3NF 就行了下面我们举例介绍
第一范式1NF 第二范式2NF 和第三范式3NF
第一范式1NF
在任何一个关系数据库中第一范式1NF 是对关系模式的基本要求不满足第一
范式1NF 的数据库就不是关系数据库
所谓第一范式1NF 是指数据库表的每一列都是不可分割的基本数据项同一列中
不能有多个值即实体中的某个属性不能有多个值或者不能有重复的属性如果出现重复
的属性就可能需要定义一个新的实体新的实体由重复的属性构成新实体与原实体之
间为一对多关系在第一范式1NF 中表的每一行只包含一个实例的信息例如对
于图3-2 中的员工信息表不能将员工信息都放在一列中显示也不能将其中的两列或多
列在一列中显示员工信息表的每一行只表示一个员工的信息一个员工的信息在表中只
出现一次简而言之第一范式就是无重复的列
第二范式2NF
第二范式2NF 是在第一范式1NF 的基础上建立起来的即满足第二范式2NF
必须先满足第一范式1NF 第二范式2NF 要求数据库表中的每个实例或行必须可
以被惟一地区分为实现区分通常需要为表加上一个列以存储各个实例的惟一标识如
图3-2 员工信息表中加上了员工编号emp_id 列因为每个员工的员工编号是惟一的
因此每个员工可以被惟一区分这个惟一属性列被称为主关键字或主键主码
第二范式2NF 要求实体的属性完全依赖于主关键字所谓完全依赖是指不能存在
仅依赖主关键字一部分的属性如果存在那么这个属性和主关键字的这一部分应该分离
出来形成一个新的实体新实体与原实体之间是一对多的关系为实现区分通常需要为表
加上一个列以存储各个实例的惟一标识简而言之第二范式就是非主属性非部分依赖
于主关键字
第三范式3NF
满足第三范式3NF 必须先满足第二范式2NF 简而言之第三范式3NF
要求一个数据库表中不包含已在其它表中已包含的非主关键字信息例如存在一个部门
信息表其中每个部门有部门编号dept_id 部门名称部门简介等信息那么在图3-2
的员工信息表中列出部门编号后就不能再将部门名称部门简介等与部门有关的信息再加
入员工信息表中如果不存在部门信息表则根据第三范式3NF 也应该构建它否则
就会有大量的数据冗余简而言之第三范式就是属性不依赖于其它非主属性
数据库设计专题：
http://www.csdn.net/subject/251/
2:
看看你的设计是不是满足第三范式3NF .
范式
构造数据库必须遵循一定的规则在关系数据库中这种规则就是范式范式是符合
某一种级别的关系模式的集合关系数据库中的关系必须满足一定的要求即满足不同的
范式目前关系数据库有六种范式第一范式1NF 第二范式2NF 第三范式3NF
第四范式4NF 第五范式5NF 和第六范式6NF 满足最低要求的范式是第一
范式1NF 在第一范式的基础上进一步满足更多要求的称为第二范式2NF 其余
范式以次类推一般说来数据库只需满足第三范式3NF 就行了下面我们举例介绍
第一范式1NF 第二范式2NF 和第三范式3NF
第一范式1NF
在任何一个关系数据库中第一范式1NF 是对关系模式的基本要求不满足第一
范式1NF 的数据库就不是关系数据库
所谓第一范式1NF 是指数据库表的每一列都是不可分割的基本数据项同一列中
不能有多个值即实体中的某个属性不能有多个值或者不能有重复的属性如果出现重复
的属性就可能需要定义一个新的实体新的实体由重复的属性构成新实体与原实体之
间为一对多关系在第一范式1NF 中表的每一行只包含一个实例的信息例如对
于图3-2 中的员工信息表不能将员工信息都放在一列中显示也不能将其中的两列或多
列在一列中显示员工信息表的每一行只表示一个员工的信息一个员工的信息在表中只
出现一次简而言之第一范式就是无重复的列
第二范式2NF
第二范式2NF 是在第一范式1NF 的基础上建立起来的即满足第二范式2NF
必须先满足第一范式1NF 第二范式2NF 要求数据库表中的每个实例或行必须可
以被惟一地区分为实现区分通常需要为表加上一个列以存储各个实例的惟一标识如
图3-2 员工信息表中加上了员工编号emp_id 列因为每个员工的员工编号是惟一的
因此每个员工可以被惟一区分这个惟一属性列被称为主关键字或主键主码
第二范式2NF 要求实体的属性完全依赖于主关键字所谓完全依赖是指不能存在
仅依赖主关键字一部分的属性如果存在那么这个属性和主关键字的这一部分应该分离
出来形成一个新的实体新实体与原实体之间是一对多的关系为实现区分通常需要为表
加上一个列以存储各个实例的惟一标识简而言之第二范式就是非主属性非部分依赖
于主关键字
第三范式3NF
满足第三范式3NF 必须先满足第二范式2NF 简而言之第三范式3NF
要求一个数据库表中不包含已在其它表中已包含的非主关键字信息例如存在一个部门
信息表其中每个部门有部门编号dept_id 部门名称部门简介等信息那么在图3-2
的员工信息表中列出部门编号后就不能再将部门名称部门简介等与部门有关的信息再加
入员工信息表中如果不存在部门信息表则根据第三范式3NF 也应该构建它否则
就会有大量的数据冗余简而言之第三范式就是属性不依赖于其它非主属性
txlicenhe 2003-11-24
- 打赏
- 举报
联机帮助：
FOREIGN KEY 约束
外键 (FK) 是用于建立和加强两个表数据之间的链接的一列或多列。通过将保存表中主键值的一列或多列添加到另一个表中，可创建两个表之间的链接。这个列就成为第二个表的外键。
当创建或更改表时可通过定义 FOREIGN KEY 约束来创建外键。
例如，数据库 pubs 中的 titles 表与 publishers 表有链接，因为在书名和出版商之间存在逻辑联系。titles 表中的 pub_id 列与 publishers 表中的主键列相对应。titles 表中的 pub_id 列是到 publishers 表的外键。
FOREIGN KEY 约束并不仅仅只可以与另一表的 PRIMARY KEY 约束相链接，它还可以定义为引用另一表的 UNIQUE 约束。FOREIGN KEY 约束不允许空值，但是，如果任何组合 FOREIGN KEY 约束的列包含空值，则将跳过 FOREIGN KEY 约束的校验。
说明 FOREIGN KEY 约束可引用同一数据库中的表或同一表（自引用表）内的列，例如，一个包含下面三列的雇员表：employee_number、employee_name 和 manager_ employee_number。由于经理本身也是雇员，所以从 manager_employee_number 列到 employee_number 列存在外键关系。
尽管 FOREIGN KEY 约束的主要目的是控制存储在外键表中的数据，但它还可以控制对主键表中数据的修改。例如，如果在 publishers 表中删除一个出版商，而这个出版商的 ID 在 titles 表中记录书的信息时使用了，则这两个表之间关联的完整性将被破坏，titles 表中该出版商的书籍因为与 publishers 表中的数据没有链接而变得孤立了。FOREIGN KEY 约束防止这种情况的发生。如果主键表中数据的更改使之与外键表中数据的链接失效，则这种更改是不能实现的，从而确保了引用完整性。如果试图删除主键表中的行或更改主键值，而该主键值与另一个表的 FOREIGN KEY 约束值相关，则该操作不可实现。若要成功更改或删除 FOREIGN KEY 约束的行，可以先在外键表中删除外键数据或更改外键数据，然后将外键链接到不同的主键数据上去。
FOREIGN KEY 约束是索引的候选约束，其原因有以下两点：
对 PRIMARY KEY 约束的更改可由相关表中的 FOREIGN KEY 约束校验。
当在查询中组合来自相关表中的数据时，经常在联接条件中使用外键列，方法是将一个表的 FOREIGN KEY 约束中的列与另一个表中的主键列或唯一键列匹配。索引使 Microsoft® SQL Server™ 2000 得以快速查找外键表中的相关数据。但是，创建索引不是必需的。即使没有在表间定义 PRIMARY KEY 或 FOREIGN KEY 约束，也可以对来自两个相关表中的数据进行组合，但两个表间的外键关系说明已用其键作为条件对其进行了优化，以便组合到查询中。有关在联接中使用 FOREIGN KEY 约束的更多信息，请参见联接基础知识。
FOREIGN KEY 约束
外键 (FK) 是用于建立和加强两个表数据之间的链接的一列或多列。通过将保存表中主键值的一列或多列添加到另一个表中，可创建两个表之间的链接。这个列就成为第二个表的外键。
当创建或更改表时可通过定义 FOREIGN KEY 约束来创建外键。
例如，数据库 pubs 中的 titles 表与 publishers 表有链接，因为在书名和出版商之间存在逻辑联系。titles 表中的 pub_id 列与 publishers 表中的主键列相对应。titles 表中的 pub_id 列是到 publishers 表的外键。
FOREIGN KEY 约束并不仅仅只可以与另一表的 PRIMARY KEY 约束相链接，它还可以定义为引用另一表的 UNIQUE 约束。FOREIGN KEY 约束不允许空值，但是，如果任何组合 FOREIGN KEY 约束的列包含空值，则将跳过 FOREIGN KEY 约束的校验。
说明 FOREIGN KEY 约束可引用同一数据库中的表或同一表（自引用表）内的列，例如，一个包含下面三列的雇员表：employee_number、employee_name 和 manager_ employee_number。由于经理本身也是雇员，所以从 manager_employee_number 列到 employee_number 列存在外键关系。
尽管 FOREIGN KEY 约束的主要目的是控制存储在外键表中的数据，但它还可以控制对主键表中数据的修改。例如，如果在 publishers 表中删除一个出版商，而这个出版商的 ID 在 titles 表中记录书的信息时使用了，则这两个表之间关联的完整性将被破坏，titles 表中该出版商的书籍因为与 publishers 表中的数据没有链接而变得孤立了。FOREIGN KEY 约束防止这种情况的发生。如果主键表中数据的更改使之与外键表中数据的链接失效，则这种更改是不能实现的，从而确保了引用完整性。如果试图删除主键表中的行或更改主键值，而该主键值与另一个表的 FOREIGN KEY 约束值相关，则该操作不可实现。若要成功更改或删除 FOREIGN KEY 约束的行，可以先在外键表中删除外键数据或更改外键数据，然后将外键链接到不同的主键数据上去。
FOREIGN KEY 约束是索引的候选约束，其原因有以下两点：
对 PRIMARY KEY 约束的更改可由相关表中的 FOREIGN KEY 约束校验。
当在查询中组合来自相关表中的数据时，经常在联接条件中使用外键列，方法是将一个表的 FOREIGN KEY 约束中的列与另一个表中的主键列或唯一键列匹配。索引使 Microsoft® SQL Server™ 2000 得以快速查找外键表中的相关数据。但是，创建索引不是必需的。即使没有在表间定义 PRIMARY KEY 或 FOREIGN KEY 约束，也可以对来自两个相关表中的数据进行组合，但两个表间的外键关系说明已用其键作为条件对其进行了优化，以便组合到查询中。有关在联接中使用 FOREIGN KEY 约束的更多信息，请参见联接基础知识。
