在Telerik Radgrid中，最好使用哪种类型的绑定？

发布于 2025-02-05 09:07:53 字数 446 浏览 1 评论 0原文

我已经通过使用 telerik radgrid 。我使用大量数据（约100万个记录）。我通过使用 header上下文菜单。我注意到过滤通常需要太多时间。我需要等待超过5分钟，直到可以将过滤器应用于下一列。使用客户端绑定而不是服务器端以增强过滤过程是一个好主意吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

乖乖哒 2025-02-12 09:07:53

是ListView，GridView还是说其他第三方控件？

它们适合Aobut 500，也许是1000个倒置。如前所述30-40，那么我们可以并且将使用数据寻呼机。但是，如前所述，所有的行仍在拉动。

但是，您的瞬间超过了大约1000行？然后，您必须倾倒内置数据呼射，并采用真实和真实的SQL Server分页。

从2012年SQL开始，他们添加了一些附加的分页选项，因此，如果您击中100万行的桌子，但仅显示30个页面，则只会拉30行。您需要采用服务器端的分页，如上所述，超过1000行的任何东西都太大且大，无法使用内置的数据拨打器（它们通过首先拉动所有行来工作 - 您不能再做了）。

因此，这意味着您必须丢弃内置的打印机，然后滚动。您需要跟踪您所在的页码，但是SQL Server的基本模板是这样的：

--CREATING A PAGING WITH OFFSET and FETCH clauses IN "SQL SERVER 2012"
DECLARE @PageNumber AS INT, @RowspPage AS INT
SET @PageNumber = 2
SET @RowspPage = 10 
SELECT ID_EXAMPLE, NM_EXAMPLE, DT_CREATE
FROM TB_EXAMPLE
ORDER BY ID_EXAMPLE
OFFSET ((@PageNumber - 1) * @RowspPage) ROWS
FETCH NEXT @RowspPage ROWS ONLY;

因此，当然可能会在商店过程中包装上面的一个，并且您将传递所需的页码。

因此，这样，当您击中排序或其他任何内容时，数据操作只会在30个记录（或您拥有的任何页面大小）上发生，因此您的性能问题应该消失。

因此，以分页为伪造的真实数据分页，如上所述，它适用于最大1000行。任何更大的东西，您都必须倾倒内置的分页方法，并根据上述概念自己滚动。

Be it listview, gridview, or say other 3rd party controls?

They are good for aobut 500, maybe 1000 reocrds. As noted beyond say 30-40, then we can and will use a data pager. But, as noted, ALL rows are still being pulled.

But, the VERY instant you get beyond about 1000 rows? then you have to dump the built in data pagers, and adopt REAL AND TRUE sql server paging.

From sql 2012 onwards, they added some additonal paging options, and thus if you hit a table with 1 million rows, but only are displaying 30 per page, then only 30 rows will be pulled. You quite MUCH HAVE to adopt server side paging, and as noted, anything beyond 1000 rows is WAY TOO HUGE AND LARGE to use a built in data pager (they work by pulling all rows first - you can't do that anymore).

So, that means you have to dump the built in pager, and roll your own. You need to keep track of the page number you are on, but the basic template for sql server works like this:

--CREATING A PAGING WITH OFFSET and FETCH clauses IN "SQL SERVER 2012"
DECLARE @PageNumber AS INT, @RowspPage AS INT
SET @PageNumber = 2
SET @RowspPage = 10 
SELECT ID_EXAMPLE, NM_EXAMPLE, DT_CREATE
FROM TB_EXAMPLE
ORDER BY ID_EXAMPLE
OFFSET ((@PageNumber - 1) * @RowspPage) ROWS
FETCH NEXT @RowspPage ROWS ONLY;

So, one of course probably would wrap above in a store procedure, and you pass the page number you want.

so, that way, when you hit sort, or whatever, you data operations will only occur on 30 records (or whatever page size you have), and thus you performance issues should go away.

so, built in paging kind of fakes real data paging , and as noted, that works for about max 1000 rows. Anything larger, you have to dump the built in paging methods, and roll your own based on the above concept.

回复收藏 0 原文

~没有更多了~