What is a resonable maximum DB rows for built-in GridView paging?

Question

I'm using a simple GridView to display some tabular data straight from a SQL Server DB. I know using the built-in paging functionality is inefficient because it pulls the entire dataset on every bind. At the moment that's fine, there are only a few dozen rows.

The data rows themselves are... about 6 nvarchar(50) columns, a couple ints, a couple floats.

The question is, at what point do I need to implement some custom paging? 500 rows? 5000? 50000?

Maybe a tough question to answer. Need more information?

Answer 1

It really depends on when it starts to slow down and how important it is to you. There is not magic number. You may be able to put indexes and other things in place to speed it up and not have to worry about it for a long time. Ideally, you should never return more than the rows being used.

Answer 2

Can you profile with test data? If so I highly recommend just trying increasing amounts of rows until it becomes too slow for you. By doing so you will probably gain some insight you cannot get any other way than trying yourself.

Having said that, I personally never just bind from the database, I always have a glue object that manages the datasource and gets exactly what is needed for the page. It might very well not be worth spending the time on that for you though.

Answer 3

It depends on the number of users hitting the web application as well as the volume of data that needs to be displayed in the grid because by not using custom paging you are putting more load on the web server. Personally I always implement data paging when the volume > 1000 rows.

Answer 4

Given the choice I would never use it, its not a great deal of work to implement custom paging and will give you a much more scalable solution. If you use the built in provider you 're always going to wonder at what point will it start slowing things down.