Sybase ASE 12.5 是否支持公用表表达式?
我注意到 Sybase SQL Anywhere 支持它们,但找不到任何关于 ASE 也这样做的文档。
如果没有,设计递归查询的最佳选择是什么?在 SQL Server 2008 中,我会使用 CTE 来完成此操作,但如果不可用怎么办?也许是一个函数?
I noted that Sybase SQL Anywhere supports them, but can't find any documentation on ASE also doing so.
If it doesn't, what would be my best option for designing a recursive query? In SQL Server 2008 I'd do it with a CTE, but if that's not available? A function perhaps?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
Sybase ASE 12.5(以及 15.0)不支持 CTE。
您可以使用内部查询来解决您的问题。
像这样的简单 CTE:
与此相同:
有关更多信息,请检查 这个!
Sybase ASE 12.5 (and also 15.0) doesn't support CTE.
You can use a inner query to solve your problem.
A simple CTE like this:
is the same as this:
For a litle more info, check this!
自 1984 年以来,标准和 Sybase 允许完全递归。我们一般在存储过程中进行递归,这样可以控制深度,避免无限循环,执行速度比未编译的SQL更快等等。
存储过程对递归、结果集构造等没有限制。当然,将括号的内容定义为视图会使其再次更快(毕竟它是一个真正的视图,而不是我们必须将每个视图具体化)我们需要它的时候)。
重点是,如果您像我一样习惯了这种方法(服务器中的递归,为递归编码的过程),则不需要 CTE 及其新语法;未编译的速度;临时表;工作台;光标“行走”层次结构;所有这些都导致了可怕的性能。
递归过程仅读取数据,仅读取数据,并且仅读取符合每个递归级别的行。它不使用游标。它不“行走”,而是构建层次结构。
第二个选项是使用动态 SQL。只需构建 SELECT,层次结构的每一层一个,然后不断添加 UNION,直到用完所有级别;然后执行。
您可以使用函数来提供 CTE 的功能,但不要这样做。函数旨在用于不同的、面向列的目的,代码受这些约束的约束。它是标量,适合构造列值。存储过程和 CTE 是面向行的。
Since 1984, the Standard, and Sybase, allowed for full recursion. We generally perform recursion in a stored proc, so that depth is controlled, infinite loops are avoided, and execution is faster than uncompiled SQL, etc.
Stored procs have no limits to recursion, result set construction etc. Of course, defining the content of the brackets as a View would make it faster again (it is after all a real View, not one that we have to Materialise every time we need it).
Point being, if you were used to this method (recursion in the server, a proc coded for recursion), as I am, there is no need for CTEs, with its new syntax; uncompiled speeds; temp tables; work tables; a cursor "walking" the hierarchy; all resulting in horrendous performance.
A recursive proc reads only the data, and nothing but the data, and reads only those rows that qualify at each level of the recursion. It does not use a cursor. It does not "walk", it builds the hierarchy.
A second option is to use Dynamic SQL. Simply construct the SELECTs, one per level of the hierarchy, and keep adding the UNIONs until you run out of levels; then execute.
You can use a function to provide the facility of a CTE, but do not do so. A function is intended for a different, column-oriented purpose, the code is subject to those constraints. It is scalar, good for constructing a column value. Stored procs and CTEs are row-oriented.