Por*_*jim 2 sql join natural-join relational-database
这个问题来自我对CJ Date的SQL和关系理论的解读:如何编写准确的SQL代码并查找互联网上的连接(包括在NATURAL JOIN上发现多个帖子(以及关于SQL Server缺乏对它的支持) )
所以这是我的问题......
一方面,在关系理论中,自然连接是唯一应该发生的连接(或者至少是非常优选的连接).
另一方面,在SQL中建议不要使用NATURAL JOIN而是使用替代方法(例如带限制的内连接).
这些调和是:
和/或
？
首先,理论与实践之间的选择是一种谬误.引用Chris Date:"事实是理论 - 至少我在这里谈论的理论,这是关系理论 - 确实非常实用".
其次,考虑自然连接依赖于属性命名.请(重新)阅读准确SQL代码书的以下部分:
6.12.对属性名称的依赖.突出报价:
关系代数的运算符......都严重依赖于属性命名.
3.9.SQL中的列命名.突出报价:
强烈建议:......如果SQL中的两列代表"相同类型的信息",请尽可能给它们指定相同的名称.(这就是为什么,例如,供应商和零件数据库中的两个供应商编号列都被称为SNO而不是,例如,一个表中的SNO和另一个表中的SNUM.)相反,如果两列代表不同类型的信息,给他们不同的名字通常是一个好主意.
我想谈谈@kuru kuru pa(也是一个很好的)关于将列添加到您无法控制的表的列,例如"您正在使用的Web服务".在我看来,使用第3.9节中引用的策略(上面引用)有效地减轻了这个问题:引用:
就个人而言,我发现"天然加入被认为是危险的"态度令人沮丧.不希望听起来自以为是,但我自己的命名惯例遵循ISO 11179-5命名和识别原则的指导,导致模式非常适合自然连接.
遗憾的是,在我专业使用的DBMS产品中很快就不会支持自然连接(SQL Server):Microsoft Connect上的相关功能请求
目前已关闭,因为"无法修复",尽管目前有一个值得尊敬的+38/ - 2分
已重新开放并获得了可观的46/-2分(现在就投票:)
关于你的问题的一些要点(即使我害怕我没有回答你提出的任何问题),
"一方面,在关系理论中,自然联合是应该发生的唯一联合(或者至少是非常优选的联盟)."
这似乎表明你将理论解释为反对"其他类型"联合的禁令......这不是真的.关系理论并没有说"你不能有反连接",或"你永远不应该使用反连接",或类似的东西.它所说的是,在关系代数中,可以识别一组原始运算符,其中自然连接是唯一的"类似连接"运算符.所有其他"类似连接"的运算符,总是可以根据定义的原始运算符来表示.笛卡尔乘积,例如,是一种特殊情况下自然连接(其中一组共同属性是空的),如果你要那两个表的笛卡尔乘积做有共同属性的名称,就可以解决这个使用RENAME .例如,Semijoin是第一张桌子的自然连接,第二张桌子有一些投影.例如,Antijoin(日期书中的SEMIMINUS或NOT MATCHING)是第一个表和两个SEMIJOIN之间的关系差异.等等
"另一方面,在SQL中建议不要使用NATURAL JOIN而是使用替代方法(例如内部连接和限制)."
建议这样的事情在哪里？在SQL标准中？我真的不这么认为.重要的是要区分由ISO标准定义的SQL语言本身,以及由某个特定供应商构建的该语言的某些(/任意)特定实现.如果Microsoft建议其客户不在SQL Server 200x中使用NJ,那么该建议与某人的建议完全不同,因为有人建议不要在SQL中使用NJ.
"自然连接在真正的RDBMS中工作.然而,SQL无法完全复制关系模型,并且没有一个流行的SQL DBMS是真正的RDBMS."
虽然SQL本身确实不能忠实地遵守关系理论,但实际上与NJ的问题关系不大.
实现是否为NJ的调用提供了良好的性能,是该实现的特征,而不是语言,或"RDBMS"中"R"的"真实程度".构建一个不使用SQL的TRDBMS非常容易,这给NJ带来了荒谬的执行时间.SQL语言本身具有支持NJ所需的一切.如果一个实现支持NJ,那么NJ 也将在该实现中工作.它是否提供良好的性能,是该实现的特征,并且某些特定实现的不良性能不应该"外推"到其他实现,或者被视为SQL语言本身的特征.
"好/更好的表设计应该删除/最小化自然连接产生的问题."
自然连接产生的问题？通过在所需的列上添加显式投影(并根据需要重命名),可以轻松控制出现在连接参数中的列.就像你也想尽可能地避免SELECT*一样,原因基本相同......