|
SET @PageLowerBound = @PageSize * @PageIndex
SET @PageUpperBound = @PageLowerBound @PageSize 1
-- Create a temp table to store the select results
CREATE TABLE #PageIndex
(
IndexId int IDENTITY (1, 1) NOT NULL,
OrderID int
)
-- Insert into the temp table
INSERT INTO #PageIndex (OrderID)
SELECT
OrderID
FROM
Orders
ORDER BY
OrderID DESC
-- Return total count
SELECT COUNT(OrderID) FROM Orders
-- Return paged results
SELECT
O.*
FROM
Orders O,
#PageIndex PageIndex
WHERE
O.OrderID = PageIndex.OrderID AND
PageIndex.IndexID > @PageLowerBound AND
PageIndex.IndexID < @PageUpperBound
ORDER BY
PageIndex.IndexID
END
在社区服务器中，我们编写了一个分页服务器控件，以完成所有的数据分页。您将会看到
，我使用的就是技巧 1 中讨论的理念，从一个存储过程返回两个结果集：记录的总数和请
求的数据。
返回记录的总数可能会根据所执行查询的不同而有所变化。例如，WHERE 子句可用来约束
返回的数据。为了计算在分页 UI 中显示的总页数，必须了解要返回记录的总数。例如，
假如总共有 1,000,000 条记录，并且要使用一个 WHERE 子句将其筛选为 1000 条记录，
那么分页逻辑就需要了解记录的总数才能正确呈现分页 UI。
技巧 3 — 连接池
在 Web 应用程序和 SQL Server? 之间设置 TCP 连接可能是一个非常消耗资源的操作。Mi
crosoft 的开发人员到目前为止能够使用连接池已经有一段时间了，这使得他们能够重用
数据库连接。他们不是针对每个请求都设置一个新的 TCP 连接，而是只在连接池中没有任
何连接时才设置新连接。当连接关闭时，它会返回连接池，在其中它会保持与数据库的连
接，而不是完全破坏该 TCP 连接。
当然，您需要小心是否会出现泄漏连接。当您完成使用连接时，请一定要关闭这些连接。
再重复一遍：无论任何人对 Microsoft?.NET Framework 中的垃圾回收有什么评论，请一
定要在完成使用连接时针对该连接显式调用 Close 或 Dispose。不要相信公共语言运行库
(CLR) 会在预先确定的时间为您清除和关闭连接。尽管 CLR 最终会破坏该类，并强制连
接关闭，但是当针对对象的垃圾回收真正发生时，并不能保证。
要以最优化的方式使用连接池，需要遵守一些规则。首先打开连接，执行操作，然后关闭
该连接。假如您必须如此的话，可以针对每个请求多次打开和关闭连接（最好应用技巧 1
），但是不要一直将连接保持打开状态并使用各种不同的方法对其进行进出传递。第二，
使用相同的连接字符串（假如使用集成身份验证的话，还要使用相同的线程标识）。假如
不使用相同的连接字符串，例如根据登录的用户自定义连接字符串，那么您将无法得到连
接池提供的同一个优化值。假如您使用集成身份验证，同时还要模拟大量用户，连接池的
效率也会大大下降。尝试跟踪与连接池相关的任何性能问题时，.NET CLR 数据性能计数器
可能非常有用。
每当应用程序连接资源时，如在另一个进程中运行的数据库，您都应该重点考虑连接该资
源所花时间、发送或检索数据所花时间，以及往返的数量，从而进行优化。优化应用程序
中任何种类的进程跳跃都是获得更佳性能的首要一点。
应用层包含了连接数据层、将数据转换为有意义类实例和业务流程的逻辑。例如社区服务
|
| 共4页: 上一页 [1] [2] 3 [4] 下一页 |
评论加载中…
