I have a gridview with about 300-400 rows that I use for reporting; it needs paging and requires sorting. My choice is between these two options: a) load the 300-400 in one query and let the gridview do the paging and sorting; b) handle the paging/sorting at the data source level. I know that b) is going to be better/faster/more efficient... In my context, I'm looking to get something done relatively fast; if I choose a), will the page seem incredibly/painfully slow?
Thanks.
Use the builtin functions of the GridView and load the whole data at one go. It wouldn't be worth the effort to implement paging in database(f.e. with RowNumber) when your number of records is such small, especially because you mentioned that you are looking for a fast solution. When you enable paging in GridView the performance will suffice.
read Scott Guthrie's excellent article about paging.
How to implement a data-result search page built with ASP.NET 2.0 and Atlas that can present hundreds of thousands of row results using the ASP.NET 2.0 GridView control. The results are formatted using a “paging” based UI model – where 15 results per page are displayed, and the user can skip from page to page to see their data. For kicks I also added support for editing and deleting each individual row.
Although 300-400 rows isn't a particularly large set of data, I would certainly vote for option B since it will definitely be more scalable. Once you start getting massive sets of data, loading all of it with one query and having the GridView handle the paging will end up being incredibly slow. The better option is to, like you said, only query the data you need for each page.
However, if you aren't going to have data sets larger than 300-400 records, you probably don't need to be too concerned about load times, but again, the key is in scalability.
Related
The project I am currently working requires retrieving/searching from large amount of data, the flow as below:-
Enter a keyword and search from about 500,000 members
Retrieve only top 6 members.
Allow sorting based on the member country or gender.
Requirements: Using EF5.0
The data is currently displayed using a UserControl and DataBinded using Repeater, will be updated through an UpdatePanel with next, previous button, etc.It is preferably but not limited to using EF5.0, and I am opened to other options (e.g. SqlDataReader) and cast it back to the members object manually.
My current solution calling the Entities with skip by using the page number, i.e.
members = context.Members.Where( conditions here ).Skip(page number * size).Take(size);
My question will be: Is my strategy the industrial / common ways of doing it? Anyone with similar experience can share with me in terms of performance / optimization, is there any other better way to do so?
I got really good performance using a stored procedure, instead of a LINQ query. This saves performance because of the query metadata generation/sql translation. If you are returning a large result set, disabling change tracking is a good option too.
I am using database paging which uses ROWCOUNT check it here https://web.archive.org/web/20211020131201/https://www.4guysfromrolla.com/webtech/042606-1.shtml and it gives really good performance with 200000 records including sorting and paging.
whats are methods to keeping datasource for a gridview.
situation :
I have a query which can take 5 to 10 seconds (a lot of link on a lot of data).
The result is too big for a page so I have a paging on my grid.
But, every time I use the pageIndexChanged, I need to get the datasource again.
So I want to know how I can keep my datasource.
Is it possible? NOT by session.
It is possible, I have used a custom (server-side) viewstate provider to cache your datasource.
*Updated: There is a pretty good article on custom viewstate providers (with sample code) here: http://www.codeproject.com/Articles/8001/ViewState-Provider-an-implementation-using-Provide
However, I would strongly recommend improving your query to limit the data to that which the user really wants to see. Large grids that have many more rows than the user is truly interested in are unwieldy from memory, processor, bandwidth, and user-experience perspectives. Try to find a better way.
I'm populating a GridView with code, setting datasource to the dataset returned by a query. So apparently sorting and paging don't just work magically like if I use a datasourceid= some sqldatasource.
I've found a number of examples of how to do this on the web, but they all appear to re-execute the query every time. Shouldn't the contents of the query be saved in the view state? Is there some way to just get the previous query results and re-sort without having to go back to the database? (Is it saving all the data in the view state? If so, why can't I get to it? It seems pretty dumb to send it all to the user's browser and send it all back, wasting all the bandwidth, if there's no way to get to it.)
Also, if I try to allow paging, it appears I again have to re-execute the query every time the user goes to another page. And if the user sorts and then pages, then I have to remember what the sort order was in a hidden field or some such, so I can re-read the data, re-sort, and then go to the right page.
Given that when you use a data source control all this behavior is built in, I think I'm missing something here. But given all the examples out there that do it this slow, hard way, if I'm missing something, a lot of other programmers are missing it, too.
If you're using an ASP.NET GridView control every time you sort a column or page through the data set then you're making a server postback. Sorting and paging with this particular control has never worked 'magically' and has long been a bugbear of mine.
You can speed things up by storing the data source that you're building the grid from in memory, either as a session or through the ViewState. Both have pros and cons and I suggest you read up.
If at all possible I suggest forgetting the ASP.NET GridView and looking at a client side solution such as the jQuery jqGrid. It uses AJAX calls to sort and page and is much, much faster and less of a headache. The only drawback is the learning curve but believe me it's worth it in the long run.
Yes the gridview re-execute the query every time.
If the query takes too long, you can manually store data in the session, or ViewState. And in the Algorithm that populates the grid just read them directly for it, instead of running the query.
you can, in the page load event, run the query one time when there is no postback (you can check for postback with
if (!Page.IsPostBack){
//Run the query and save it to the session
}
and the the method that populate the grid, should read from the session directly. no need to run the query again
Say I have 2 tables in a database, each with 100,000's of rows in detail and 10,000's of rows in the master 5 columns each, properly indexed and related. I want to have master/detail nested gridviews. What's the fastest architecture I could design in .net to do this? The largest result set on the master could be in the thousands (usually in the tens though) and the detail per records could be in the hundreds (usually in the single digits though). I'd like to be able to do a display all masters if possible.
The bottom line: bind to DataReaders, use Repeaters instead of GridViews, and turn off ViewState.
The design you're proposing is going to be pretty hard on your users (thousands of records, yikes), but you probably already know that.
If this is just for display and you want the absolute fastest architecture for Asp.Net, you should obtain an IDataReader for each data segment (master and child), sorted such that you can manually match child records while reading both resultsets in a forward-only fashion. (See Scott Mitchell's Why I don't Use DataSets in my ASP.NET Applications for some details about DataReader performance - as long as you aren't optimizing prematurely, it's quite good advice.)
Instead of using a GridView, I'd use a Repeater which has less overhead and lets you write more compact HTML (for a smaller payload to the client): bind the master IDataReader to that repeater. (I'm not sure whether you meant the GridView control, or just a conceptual grid - the basic architecture would be the same for a GridView)
Then add a handler to the Repeater.ItemDataBound that checks if the child data reader's current record matches. If it does, manually render your detail data for that master record.
Finally, you should also turn ViewState off, at least for the Repeater (preferably for as much of the page as possible), again so that the HTML payload is smaller.
If you're totally committed to nested GridViews, particularly to using a GridView to render the detail data, it's going to hurt the performance one way or another, because you'll have to either make many more database calls (to obtain discrete resultsets you can bind to) or you'll have to massage the detail data into an intermediary container.
They seem to be so nasty.
I have a gridview, and the query it runs pulls back 10,000 results if no filters are set... and displays 10 of them on the first page. You press page 2, and then it does the query again... and again...
Isn't there a way to cache them? Isn't there a much easier way to bring in all the results then filter them live without repeated queries? Must ASP.NET be all about a struggle against the gridview?
I would love to know if there is a better way...
Which grid are you using? GridViews will bind to anything that implements IEnumerable, so do you realise that you can fetch the data and explicitly bind it yourself? Similar to:
List<myDataObjects> data = executeMyQuery();
gridview.DataSource = data;
gridView.DataBind();
this way you can control when the data is fetched, and you can even cache it if required.
If you're using SQL Server 2005 and above, you can make use of the ROW_NUMBER() function in your query, which you can use to page the rows returned at source.
ScottGu has a detailed blog post here using a DataList, but this is equally applicable to GridViews
This blog entry has a more concise introduction to the specifics of ROW_NUMBER()
Instead of performing a query which returns everything in one big resultset, consider returning your results in a paged fashion.
You can put the results in the ViewState, but this isn't really advisable if you have a lot of data which can be returned.
Use a repeater and create your queries to only return the results you need. Your query will probably need to make use of parameters for resultsPerPage and PageNumber.
Gridviews connected to those datasets are good for 5 minute demos, but really shouldn't end up in production code. Nasty is good word for it.