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

关于速度的问题，我觉得不用担心，因为内建执行命令本身在数据库内存中有缓存，可以重复利用。

关于数据设计，是需要仔细考虑，最好是基于对象建模的角度去出发，这一点可以参考EJB的设计要点，其实论坛上的相关话题已经很细化了。
这是因为如果你是大表的话，怕删错东西。

做过MIS系统的都知道，一般说来，数据分为两种：基础数据和业务数据。一般说来，业务数据中肯定包含多个基础数据，比如简单地说一张机票数据，它就包括：货币类型、机场、航空公司等多个基础数据，这个时候，如果都要建立FK的话，是没有任何意义的，更不需要去考虑什么级联删除的，结果只有一个，严重影响效率，而且结构凌乱。但是在业务数据中，机票的基本信息和机票的价格构成了一个整体，这个时候如果不使用FK，那么在设计上是个失误，在实现的时候也绝对是个隐患！比如删除的时候，删除了机票，但是留下了机票的价格，大家可以相信，这是多么荒谬的事情。
    所以，使不使用FK，关键要区分基础数据和业务数据。
    另外，一个好的数据库设计并不是纯粹考虑数据库，而是来源于好的业务建模和对象建模。

就那你的例子来说，如果机票数据包含有货币类型等等，我再假设，机票数据是一张表，货币类型也是用一张表来记录，那么table-机票数据中包含有一个字段记录货币类型表的id。那么这个id仅仅是设计者和开发者知道是指向货币类型表的id，而不设置外建约束，是吗？

如果我对你话理解是正确的话，那么我得问题是：
如果货币种类的某条记录删除的话，那么机票数据中依然保持着这个不存在的id，从而破坏数据一致性。

总之问题归节为：事实上存在外建关系的表，不管是基础数据，还是业务数据，如果不引入外建约束，将破坏数据一致性－起码可能破坏一致性！我想知道的是，既然如此，为什么存在这样的大量设计的实例。

首先基础数据的不存在并不能代表业务数据的不存在或者逻辑错误，其次，比如基础数据，是不能随意删除的，当然，我们有很多的控制方法，比如失效等什么的。对于基础数据不用外键是综合各方面考虑的，不是说不能用外键，但是用了外键将导致一个非常可怕的问题，就是数据访问的问题，每访问一个业务数据，那么意味着有可能要join访问10个以上的表，效率会严重降低。
    好的数据库设计不能是没有一点冗余，或者说严格符合关系要求，因为实际的应用是面向对象的，在将面向对象的数据转换为面向关系的数据时，是需要这样做的。从逻辑上说，一个基础数据的不存在，并不代表什么，比如说，你没有输入一个国家或者删除一个国家，并不代表没有了这个国家。而业务数据就不同了，如果你删除了一张业务数据，那么就代表了该业务数据已经不存在，而此时再存在与之相关的业务数据是不符合逻辑的（比如一个法规作废，那么与之相关的法规就都必须受影响）。
   
    好的数据库设计来自于好的对象设计。

可能是我的表达不够明白，

即便是不使用外建约束，查询的时候照样还是要join啊。不同的是没有设定外建约束，数据库系统将不保证数据一致性。

你所说的是另一个话题：数据库设计中存在冗余字段和性能之间的平衡问题。

我所说的是，假设数据库设计没有问题，存在外建关系的表之间，我们是不是一定要用系统来约束他。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
例子：
表：user,group
user：
int userid ,
int groupid,
varchar user_name,

group:
int groupid
varchar group_name,

我们是否需要加上：
alter table user add constraint FK260CC057D5C0A5 foreign key (groupid) references group;

??
因为很多数据库设计并没有加上这句话，一点好奇而已。

关于外键，我想，jive之类的应用就一定是标准吗？我认为未必。

外键约束是用来维护引用完整性的，关于它的精确定义我也记不住了，但规范并没有限定它的实现。外键约束是如何实现的，完全由具体的数据库产品自行决定。——记得好像有三种实现方式。

jive有个特点，就是支持的数据库种类很多，如果考虑到不同的实现（甚至可能有不支持外键的数据库）对程序的影响，那就只好由程序控制了。

我的想法是，假如，程序要支持不同的数据库，那么数据库的专有特性就要少用。
假如，数据库要支持不同的程序，那数据库的专有特性就要多用一点——尤其是保证数据的完整性和一致性的特性。

我自己是用pd建模，然后生成数据库脚本的，由于以前用的是SQLServer，所以物理模型都有生成外键。使用中也没发现什么问题——当然，项目小，看不出来也不出奇。

至于性能问题，我想不是主要的考虑因素，即使可能有影响也不应该在设计阶段考虑。数据库性能的优化主要还是在表结构的设计，SQL的写法及索引上。真的要作优化时，也应该首先考虑这些，只有在严格的测试证明确
实是这部分出问题了，才应该考虑。我没做过测试，不知道要多大的压力这个性能差别才会体现出来，希望有这方面经验的朋友能指点一下。


我比较看重数据的完整性和一致性，可能的话，我会交给数据库来做。这个也是数据库的主要设计目标之一。

数据库，不只是数据的容器。

我对于判定是否使用外键的标准——是否需要维护“引用完整性”？对数据库来说，是不区分业务数据及逻辑数据的

嗯，楼上的说法，很赞同。
也许正如你所说我看到的很多都是基于mysql开发的，而一般都没有采用innodb，所以都没有外建设定。

为了更好的理解我的意思，请参看一下业务主键和逻辑主键哪个更好的帖子。
    这样说吧，如果你在基础表中用的是逻辑主键，那么，业务表用外键的话，将自然引用的是逻辑值（比如毫无意义的数字或UUID），这样，如果你想查找一个业务表，那么你自然就需要去join更多的表。
    你会说，基础表采用业务主键就是。但你有没有想过，一般来说，基础表是不少的，一个业务表同时要引用多个基础表或者多次引用一个基础表，如果真是建立了外键的，那么DBMS维护这个外键都是非常可怕的事情。
    我不知道你做数据库的是否会先进行数据模型设计，如果是的话，那么你就可以领略这种恐怖性了！错综复杂的关系将使你数据库的性能，数据模型的清晰性严重降低，同时你的数据结构复杂性大为上升。
    一个好的数据库设计不是盲目去追求范式，我们现在所用的数据库全部是关系数据库，而思想应该是面向对象的。将面向对象的思想实现为面向关系的存储。
    永远记住一点，好的数据库设计永远都是来自好的对象设计。

其实我更赞同凤舞凰扬的观点，在业务表中引用master data不建议采用太多的FK。
基础数据一般是比较稳定的，例如一个销售订单，里面引用了一个国家，大家知道，国家这些数据难道我们会经常删除它吗？而现在这个国家真的不存在了，我确实要删除他，那么与这个国家相关的资料是不是都要删除呢？难道和这个曾经存在过的国家相关的数据就完全没有意义了吗？数据库设计怎能不考虑业务问题呢？

我对于判定是否使用外键的标准——是否需要维护“引用完整性”？对数据库来说，是不区分业务数据及逻辑数据的

这句话很清楚了，讨论的问题不是要不要用外建，和采用那种外建。
而是外建关系存在的时候，是否要加上约束。问题就此作罢吧。

凤兄的建议，我会好好揣摩的，有问题再请教，谢了：）