SQL Server 2008 中的分页
我是 SQL Server 的新手。保留这个问题作为参考。我的疑问是
为什么 Microsoft Sql 服务器在 Mysql 中没有类似限制的东西,现在他们强制编写 SP 或内部查询进行分页。我认为创建临时视图/表或使用内部查询将是比简单的查询慢。我相信有充分的理由反对这一点。我想知道原因。
如果有人知道请分享一下。
I am a newbie to SQL server. keeping this question as reference.My doubt is
why Microsoft Sql server doesn't have something like limit in Mysql and now they are forcing to write either SP or inner query for pagination.I think creating a temporary view/table or using a inner query will be slower than a simple query.And i believe that there will be a strong reason for deprecating this. I like to know the reason.
If anyone know it please share it.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我从来不知道 SQL Server 支持像
TOP 10,20
这样的东西 - 你真的完全确定吗?难道这不是其他系统吗?无论如何:SQL Server 2011(代号“Denali”)将在 2011 年底左右发布时添加更多对此的支持。
ORDER BY
子句将获得新的附加关键字OFFSET
和FETCH
- 了解有关它们的更多信息 MSDN 上。您将能够编写如下语句:
I never knew SQL Server supported something like
TOP 10,20
- are you really totally sure?? Wasn't that some other system maybe??Anyway: SQL Server 2011 (code-named "Denali") will be adding more support for this when it comes out by the end of 2011 or so.
The
ORDER BY
clause will get new additional keywordsOFFSET
andFETCH
- read more about them here on MSDN.You'll be able to write statements like:
SQL Server 2005 分页 – 圣杯(需要免费注册)。
(虽然它说SQL Server 2005,但它仍然适用于SQL Server 2008)
SQL Server 2005 Paging – The Holy Grail (requires free registration).
(Although it says SQL Server 2005 it is still applicable to SQL Server 2008)
我百分百同意! MySQL 有 LIMIT 子句,它使返回一系列行的语法非常简单。
我不确定临时表语法是否较慢,因为 SQL Server 可能能够进行一些优化。然而,输入 LIMIT 子句要容易得多。我预计也会有更多优化的机会。
我以前曾提出过这个问题,但与我交谈的小组似乎并不同意。
就我而言,没有理由不使用 LIMIT 子句(或等效子句),并且我强烈怀疑 SQL Server 最终会这样做!
I agree 100%! MySQL has the LIMIT clause that makes a very easy syntax to return a range of rows.
I don't know for sure that temporary table syntax is slower because SQL Server may be able to make some optimizations. However, a LIMIT clause would be far easier to type. And I would expect there would be more opportunities for optimization too.
I brought this once before, and the group I was talking to just didn't seem to agree.
As far as I'm concerned, there is no reason not to have a LIMIT clause (or equivalent), and I strongly suspect SQL Server eventually will!