提问：关于数据库设计中外建的运用

我看到的一些项目中，当数据表之间存在明显的外建约束的情况下，但是数据库的设计却只是简单的在子表中包含一个父表id的字段，而没有任何约束存在，从理论上来说，为保证数据的一致性，是应该加上外建约束的。但是这种情况存不算是少量了，除开mysql不支持外建之外，是否还有隐情？

还有一个问题，就算是使用了外建约束，你们通常使用级连删除或者更新吗？
就是说，是自己手动删除子，然后再删除父；还是直接删除父，让数据库级连来删除子？？

我一般都采用先手动删除子，然后删除父。因为我觉得，让数据库级连处理的话，他可能还要分析表之间的约束，才进行删除操作，而这部分分析如果由我来完成的话，可能程序的执行速度会快一些，我是这样想的，不知是否正确。

MySQL 好象是支持外键的。论坛里以前有人说过。

那么，外建为什么不使用呢？比如说jive的数据库设计，就有我上面说的那样的情况。

还有这个问题呢：

一般我们在做设计的时候都会把外键考虑在内，但是在建立数据库表的时候通常是不会建外键的，考虑到开发的时候维护数据的方便性 。虽然在生产数据库中会建立外键，但是也是在程序中维护父、子表数据关系，而不是依靠外键维护。

这样不是说数据库的外建没有任何作用？？大家都不用。
那数据的一致性如何保证呢？虽然说你的程序可以控制，但是谁来保证你的程序写的正确呢？

并不是外键没有作用，外键是基于关系的，在数据级上能够保证数据的一致性。而在程序中维护关系是基于业务逻辑的，如果程序中不能保证数据的一致性，那么就是业务逻辑的实现有问题，当然，不能排除业务逻辑没有问题而在更新数据的时候由于系统的原因造成的数据一致性问题。我说的在程序中维护只是一种方式，至于外键的使用当然是见仁见智啦。

这个理由我觉得不够充分，我在开发的时候一般都使用了数据库自带的各种约束，其中有一次，有个很隐蔽的bug，如果没有约束的话，我想那个bug会存在很长时间，会花更多的时间来找这个bug，其实只是一个笔误，a表的fk写成了b表fk。这样起码可以帮助debug。

我一直是认为应该使用约束的，如果约束存在而且数据库支持的话。不过看到了不少人不这样用，有点好奇而已。

在顶一下，看看还别的看法没有。。。。

外键的级联删除用的比较少,BANQ也不太用mysql的纺联删除的，这一点我用的比较多，我还用到自关联self-referential cascade delelte。
在mysql-innodb环境是绝对没有问题的。

如果用级连删除的话，你认为我这样说对不对？