Home  >  Article  >  Database  >  从两种SQL表连接写法来了解过去

从两种SQL表连接写法来了解过去

WBOY
WBOYOriginal
2016-06-07 17:58:45851browse

如果想要优雅而易于维护且不容易写错的代码,当然用高标准的第二种方法。 如果必要考虑风险这个因素,比如涉及到多种平台的迁移或者整合,你应该用第一种,起码在两个表的情况下他还是比较安全的。

例如:一个二表连接的SQL,有两种写法:
(1)select A.c1,A.c2,B.c1,B.c2
from table1 A,table2 B
where A.id=B.id

(2)select A.c1,A.c2,B.c1,B.c2
from table1 A join table2 B
on A.id=B.id

哪种写法好呢?现在提倡用哪一种?
你喜欢用哪一种?
代码如下:
select * from a,b where a.id=b.id
select * from a inner join b on a.id=b.id


---这两个哪个好?

其中11楼的回答最为深入。其实这个问题还是有一定的历史原因的,不管你习惯什么样的写法只要知道来龙去脉就不会再被细枝末节来迷惑了。以下观点为个人认识,如有偏差欢迎指正。

简单的说,前者是ansi sql 86标准后者是ansi sql 92标准(*****) ,这个观点最容易被人接受。

什么是ansi?美国国家标准局,iso的重要成员之一,1918年就有了。
什么是ansi sql?就是ansi注意到了sql的生产力,于是规范化了一下。

什么是sql?他是ibm发明的,oracle发扬广大的一门语言。

为什么是两家公司?。
70年代初因为ibm内部各方利益斗争激烈,导致某大牛的研究成果只能以论文方式发表。
70年代末某小公司把此技术用在商业领域就成了oracle,直到n年后ibm db2才出来。

所以,sql不是ansi 发明的,ansi 标准也不能通吃所有数据库平台。

比如下面这个是什么数据库的语法?反正ansi 标准在他那里是报错的。
select * from (a inner join b on a.id=b.id) inner join c on a.id=c.id

那么在ansi86之前的数据库有哪些?oracle和db2是肯定的了。另外还有一些当时的小角色:Informix,dbase系列等。

而sybase的数据库和SQLServer是86年之后出来的,而前面那个奇怪的join语法的access是90后的。

古老的sqlserver和oracle我都没有用过,反正在02年用oracle8i时还不支持ansi 92的inner join,他是97年生的。一直到本世纪发布的oacle9i 才改了过来。用多了t-sql的人会问 left join咋办,where a.id=b.id(+) 就可以了,人家没那么笨的,t-sql以前还有*=这样的表示。


那么这么看貌似ansi的规范力度不够?其实不是,国际标准化也不可能一刀切,在ansi92 当中定义了4个级别,n多条款。大意就是大家符合入门级就行了,其他高级别仅供参考,甚至iso根本不会验证其他级别..而诸如inner join和left join之类的都是过渡级的,囧。


所以我前面打了5个星星的那句话并不是完全正确的,正确的应该是

前者符合ansi 86 标准和ansi 92入门级标准,后者符合ansi92 过渡级标准。

不是oracle8i不符合ansi92,而是没有符合ansi92的高级别规范,而完全实现高级别标准的数据库系统是没有的。

早在oracle7就已经完全符合ansi92了,当然是指入门级,而且他就是ansi92 的模版范例。

--回到上面的话题,这两个哪个好?
性能当然完全一样,区别只是习惯和喜好,但也因为标准级别不同而具有不同的风险。

如果想要优雅而易于维护且不容易写错的代码,当然用高标准的第二种方法。
如果必要考虑风险这个因素,比如涉及到多种平台的迁移或者整合,你应该用第一种,起码在两个表的情况下他还是比较安全的。

----
顺带提一句,ansi标准一直在修订:具体有多少版本就不列举了,我们得到的好处自然是多多的,比如递归、对象、数组、xml等等在各主流数据库的新版本中都陆续实现了
Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn