Chinaunix

标题: [Q] 有关外键的讨论 [打印本页]

作者: winy_huang 时间: 2004-01-18 10:00
标题: [Q] 有关外键的讨论
在一个大型的数据库中，到底要不要用外键呢？
外键会影响系统的性能，但不用的话又要在程序中进行控制。

作者: ccwlm741212 时间: 2004-01-18 10:26
1、外键一般都需要
2、外键主要解决冗余的问题
3、外键会影响系统的性能，所以适当的冗余是存在的，需要在2者间进行权衡

作者: winy_huang 时间: 2004-01-18 10:28
2、外键主要解决冗余的问题
能不能解释一下这一点？

作者: ccwlm741212 时间: 2004-01-18 10:32
A学生库=学生号码，学生姓名，班级编码（班级名称，班主任），出生年月。。。。
B班级库=班级编码，班级名称，班主任。。

班级编码就是A的外健啊，否则后面的信息必须重复定义了哦

作者: winy_huang 时间: 2004-01-18 11:06
这个我明白。
但假设我是有这几表，我也是这么建的。但我就是不加外键!
我通过程序来控制。有没有问题？
如果可以的话，那外键根本就没用了。

作者: ccwlm741212 时间: 2004-01-18 11:11

最初由 winy_huang 发布
[B]这个我明白。
但假设我是有这几表，我也是这么建的。但我就是不加外键!
我通过程序来控制。有没有问题？
如果可以的话，那外键根本就没用了。 [/B]

麻烦了啊

可以外键还可以保持数据的完整性啊

作者: winy_huang 时间: 2004-01-18 11:28
嗯。是的。
说到性能问题，如果说我的表是像上面那样建的，但我加不加外键对性能有没有影响？

作者: ccwlm741212 时间: 2004-01-18 11:32
基本没多大问题，在很大数据的统计上或许存在问题了，看具体情况的

作者: lodge 时间: 2004-01-18 15:02
恩, 使用外键的时候, 可以避免写很多代码和手工设置的索引, 数据一致性可以得到很好的保证, 即使外部程序出现BUG, 也不会破坏数据.
但是使用外键的最大问题是, 可读性很差, 很难追踪错误, 特别是需要在LOG中准确记录错误的时候, 非常不方便. 因此, 通常采用双重控制, 首先, 在外部程序中进行控制以保证可读性, 然后数据库本身也做相关设定, 以保证安全性.
在开发阶段, 为了方便测试通常不设置外键.
另外, 虽然外键设置成CASCADE就能在主表删除记录的同时自动删除子表数据, 但这样的做法常常由于无法控制子表数据的删除(比如, 留下LOG等等)很少被使用. 特别是在大型系统中, 简化系统设定, 也是非常重要的考虑. 这样的做法就更少见了.

作者: wangyuzhen 时间: 2004-01-19 10:36
我不用FK，举例说明吧
FK一般都是指向一些不常变化的代码表的，用于业务数据和代码数据之间的关联
假设代码表有2个字段，一个是代码一个是名称，当用外键的时候，一旦代码表中的名称发生改变就意味着所有的业务数据表关联的这个代码的名称都变成新版本的了，然而，很多时候我们需要保留历史状态，原来的记录中名称还是用老版本的，新加的记录就用新版本的名称。这样的应用就比较适合用数据冗余的策略来实现。
虽然，在Oracle等大型数据库中提供了一些触发可以根据规则来关联新、老版本的名称，但是，我个人认为这还是比较适合在大系统或通用系统中采用，因为，使用FK、参考、级联删除等策略只是把程序中的复杂度转移到了数据库端。只有养得起DBA或付得起服务费的单位才能用这样的系统。
个人认为比较妥当的解决方法是使用代码表的版本控制，让程序能够根据不同的条件应用不同版本的代码表。不过，这种做法很受到编程人员的抵制，主要是实现复杂、版本控制规则难确定。

作者: ccwlm741212 时间: 2004-01-19 10:41
楼上说的很对，FK的使用（业务数据和代码数据之间的关联的时候）是存在这样的问题，如果客户需要历史变动的信息的，可以这样做
1、操作日志记录
2、适当的冗余

可FK在保证数据完整性方面是很重要的一环，特别是业务数据处理的时候

作者: magicangel 时间: 2004-01-19 11:03
外键最大的好处是在数据库端保证数据的完整性。

不过，大家知道RDBMS的约束性和完整性维护起来是比较麻烦的。

当然在前台开发工具里也提供了完整性和约束。

个人意见可以根据系统的功能、复杂程度和个人特长在设计代码的时候取舍。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)