如何在没有可用的完整外连接的情况下执行完整外连接
上周我惊讶地发现 sybase 12 不支持完全外连接。 但我突然想到,完整的外连接应该与左外连接与同一sql的右外连接联合起来相同。 有人能想到一个不成立的理由吗?
Last week I was surprised to find out that sybase 12 doesn't support full outer joins.
But it occurred to me that a full outer join should be the same as a left outer join unioned with a right outer join of the same sql.
Can anybody think of a reason this would not hold true?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
UNION ALL
左联接与右联接,但将右联接限制为仅基表中不存在的行(如果它们在表中不为空,则在联接上返回 null存在)。对于此代码,您需要创建两个表 t1 和 t2。 t1 应该有一个名为 c1 的列,其中有 5 行包含值 1-5。 t2 还应该有一个 c1 列,其中有 5 行包含值 2-6。
完全外连接:
完全外连接等效项:
请注意右侧连接选择上的 where 子句,该子句将结果限制为仅那些不会重复的结果。
UNION ALL
the left join with the right join, but limit the right join to only rows that do not exist in the base table (return null on the join when they would not be null in the table if they existed).For this code you will need to create two tables t1 and t2. t1 should have one column named c1 with five rows containing the values 1-5. t2 should also have a c1 column with five rows containing the values 2-6.
Full Outer Join:
Full Outer Join Equivalent:
Note the where clause on the right joined select that limits the results to only those that would not be duplicates.
UNION
-ing 两个OUTER JOIN
语句应该会产生代表从INNER JOIN
获取的数据的重复行。您可能必须对UNION
生成的数据集执行SELECT DISTINCT
。一般来说,如果您必须使用 SELECT DISTINCT ,则意味着它不是一个设计良好的查询(或者我听说过)。UNION
-ing twoOUTER JOIN
statements should result in duplicate rows representing the data you'd get from anINNER JOIN
. You'd have to probably do aSELECT DISTINCT
on the data set produced by theUNION
. Generally if you have to use aSELECT DISTINCT
that means it's not a well-designed query (or so I've heard).如果您使用
UNION ALL
将它们联合起来,您将得到重复项。如果您只使用UNION
而不使用ALL
,它将过滤重复项,因此相当于完全连接,但查询也会更加昂贵,因为它必须执行不同的排序。If you union them with
UNION ALL
, you'll get duplicates. If you just useUNION
without theALL
, it will filter duplicates and therefore be equivalent to a full join, but the query will also be a lot more expensive because it has to perform a distinct sort.首先,我不知道你为什么使用 12.x。于 2007 年 4 月 3 日收到通知后,于 2009 年 12 月 31 日EndOfLifed。 2(第一个实体版本)于 2009 年 1 月发布。15.5 更好,并于 2009 年 12 月 2 日发布,因此是两个主要版本,并且至少已经过时了 13 个月。
ASE 12.5.4 具有新的 Join 语法。 (您没有指定,您可能使用的是 12.5.0.3,即该版本之前的版本)。
DB2 和 Sybase 没有实现
FULL OUTER JOIN
,其原因正是您所确定的:它由LEFT ... UNION ... RIGHT
覆盖,而没有 <代码>全部。这不是“不支持”FOJ 的情况;而是“不支持”FOJ 的情况。这是缺少关键字的情况。然后你会遇到这样的问题:Sybase 和 DB2 类型通常不会使用外连接,更不用说 FOJ,因为它们的数据库往往更加规范化,等等。
最后,您可以在任何版本的 Sybase 中使用完全普通的 SQL,它将提供 FOJ 的功能,并且将在 12.x 上明显更快;在 15.x 上仅稍微快一些。它有点像 RANK() 函数:如果您可以编写子查询,则完全没有必要。
它不需要像某些低端引擎那样的
FULL OUTER
的第二个原因是因为新的优化器速度非常快,并且查询是完全规范化的。 IE。它在一次传递中执行左和右。根据您的 SARG 和数据类型不匹配等,它可能仍然需要排序合并,但这也在所有三个级别上进行流式传输:磁盘 I/O 子系统;发动机;和网络处理程序。如果您的表已分区,那么它还会在该级别进行并行化。
如果您的服务器未配置并且您的结果集非常大,您可能需要增加
进程缓存大小
和排序缓冲区数量
。仅此而已。Well first, I don't know why you are using 12.x. It was EndOfLifed on 31 Dec 2009, after having been notified on 3 Apr 2007. 15.0.2 (first solid version) came out in Jan 2009. 15.5 is much better and was available 02 Dec 2009, so you are two major releases, and over at least 13 months, out of date.
ASE 12.5.4 has the new Join syntax. (you have not specified, you may be on 12.5.0.3, the release prior to that).
DB2 and Sybase did not implement
FULL OUTER JOIN
, for precisely the reason you have identified: it is covered byLEFT ... UNION ... RIGHT
withoutALL
. It is not a case of "not supporting" a FOJ; it is a case of the keyword is missing.And then you have the issue that Sybase and DB2 types would generally never use outer joins let alone FOJs, because their databases tend to be more normalised, etc.
Last, there is perfectly ordinary SQL you can use in any version of Sybase that will supply the function of FOJ, and will be distinctly faster on 12.x; only marginally faster on 15.x. It is kind of like the RANK() function: quite unnecessary if you can write a Subquery.
The second reason it does not need
FULL OUTER
, as some of the low end engines do, is because the new optimiser is extremely fast, and the query is fully normalised. Ie. it performs the LEFT and the RIGHT in a single pass.Depending on you SARGs and DataType mismatches, etc it may still have to sort-merge, but that too is streamed at all three levels: disk I/O subsystem; engine(s); and network handler. If your tables are partitioned, then it is additionally parallelised at that level.
If your server is not configured and your result set is very large, you may need to increase
proc cache size
andnumber of sort buffers
. That's all.