I noticed that in all the examples provided by the website, all data is retrieved from the database at page load. However, in my case this would result in having to retrieve a significant amount of data, from which only part of it is being edited. I am no expert, but this would seem inefficient in terms of performance. I've also seen PhpGrid.org and they seem to use AJAX calls for each page.
Would you agree, or could someone explain why the current method is in fact more efficient?
Is there a way to only retrieve data for the page that is being viewed (i.e. via AJAX calls) ?
Can someone convince me? :-)
Please refer to DataTables manual page about data for more information. Below is an excerpt:
DataTables has two different modes of processing data (ordering,
searching, etc. of data):
Client-side processing - the full data set is loaded up-front and data processing is done in the browser.
Server-side processing - an Ajax request is made for every table redraw, with only the data required for each display returned. The
data processing is performed on the server.
Each has its own advantages and disadvantages, but the key indicator
for which mode you should select is based on the number of rows in
your table.
You're referring to client-side processing mode which loads all data at once. However, in server-side processing mode only current page data is loaded which improves performance.
Related
I am using DataTable plugin in Laravel. I have a record of 3000 entries in some
But when i load that page it loads all 3000 records in the browser then create pagination, this slow down the page loading.
How to fix this or correct way
Use server-side processing.
Get help from some Laravel Packages. Such as Yajra's: https://yajrabox.com/docs/laravel-datatables/
Generally you can solve pagination either on the front end, the back end (server or database side), or a combination of both.
Server side processing, without a package, would mean setting up TOP/FETCH or make rows in data being returned from your server.
You could also load a small amount (say 20) and then when the user scrolls to the bottom of the list, load another 20 or so. I mention the inclusion of front end processing as well because I’m not sure what your use cases are, but I imagine it’s pretty rare any given user actually needs to see 3000 rows at a time.
Given that Data Tables seems to have built-in functionality for paginating data, I think that #tersakyan is essentially correct — what you want is some form of back-end filtering or paginating of rows of data to limit what’s being sent to the front end.
I don’t know if that package works for you or not or what your setup looks like, but pagination can also be achieved directly from a DataBase returning data via the SQL (using TOP/FETCH for example) or could be implemented in a Controller or Service by tracking pages of data and “loading a page at a time” both from the server and then into the table. All you would need is a unique key to associate each "set of pages" for a specific request.
But for performance, you want to avoid both large data requests and operations on large sets of data. So the more you limit how much data is being grabbed or processed at any stage of your application using it, the more performant your application will be in principle.
I have a query that takes a while to execute. The data is sent to the grid on the view and some filtering conditions may be sent from the view to the controller. I do not want to re-query the database during each filter. Is there a way to store the data loaded on the first query execution in some structure and later filter on that data? I was thinking in using something like ViewData or ViewBag but those seem not to last as long as might be needed in this case.
Or is there any other way of doing this that does not necessitate getting data from the database each time?
I am using ajax and not server binding because the of the query that takes a while. I want to be able to show the page even when the query is not done executing.
You'll have to cache your data on the server somewhere, whether that's using ASP.NET output caching, an ASP.NET state server, or a 3rd-party caching solution (like memcached). Then when you do your AJAX queries you get the data out of your cache instead of your database.
Actually you can do it with viewModel and knockout.js
Binding MVC grid to stored procedure with large amount of data:
I want to bind MVC grid to an object result that returned from SP
Normally the grid request only data needed to be shown to the user and that will be very good when binding to a table with large amount of data that lets the grid fast and its performance would be good.
i have 2 ways to bind MVC grid with SP:
Bind to SP without using .ToList() it gives me an error "The result of a query can not be enumerated more than once."
Bind to sp using .ToList() will resolve that error but it will loads all records from database first and the performance will be bad and the grid loading, paging, sorting and filtering would be very slow.
Please tell me a solution to bind MVC grid with SP that returns large amount of data with good performance.
Thank you
I have used jqgrid in the past, jqgrid implements paging so not all the content of the grid is actually displayed at once, you pick the number of rows per page and jqgrid automatically will hook the navigation to your controller. There are a lot of examples of this on the web. If you click the next page it will retrieve the appropriate data for that page and so forth.
The jqgrid page has a lot of examples in loading data that ilustrate this: http://www.trirand.com/blog/jqgrid/jqgrid.html, here is another page that talks how that is implemented at the server side using mvc http://www.codersource.net/AspNet/ASPNetAdvanced/jqGridPaginginaspnetmvc.aspx, I'm sure if you look around you'll find a lot of information on how to go about this approach.
Finally I usually avoid showing the user a lot of data anyways, mainly because it is hard for a human been to make any sense of more than 100 rows of data having a way to search further in it. So I rather try and attempt to shrink the data size giving them a way to filter it down further, but this is not always possible.
Hope this helps.
I have a situation where I was creating jqgrid empty initially with datatype as local and then later on adding nodes to jqgrid using addChildNode method. This is all done in client side javascript.
Now soon we have discovered that data is too much so javascript is taking too much time to load and we are getting warning as script is taking too long. I want to implement on demand data load , but whatever example I saw they all makes a call to server side for data load.
Do we have any such options where in I can implement on data data load and for data loading jqgrid will still make a call to client side javascript.
,This question is likely subjective, but a lot of "grid" Javascript plugins have come out to help paginate and sort tables. They usually work in 2 ways, the first and simplest is that it takes an existing HTML <table> and converts it into a sortable and searchable information. The second is that it passes info to the server and has the server select info from the database to be displayed.
My question is this: At what point (size wise) is it more efficient to use server-side processing vs displaying all the data and have the "grid plugin" convert it to a sortable/searchable table client-side?
Using datatables as an example, I have to execute at least 3 queries to get total rows in the table, total filtered results for pagination, and the filtered results to be displayed for the specific selected page. Then every time I sort, I am querying again. Every time I move to another page, or search in the table, more queries.
If I was to pull the data once when the client visits the page, I would be executing a single query, and then formatting and pushing the results to the client all at once. This increases the page size, and possibly delays loading of the page once it gets too big. The upside is there will only one query, and all the sorting, searching, and pagination is handled by the plugin, so no waiting for a response and no more queries.
If I was to have just a few rows, I imagine just pushing the formatted table data to the client at the page load would be the fastest. But with thousands of rows, switching to server-side would be the most efficient way.
Where is the tipping point? Is there a tipping point, or is server-side or client-side the way to go 100% of the time?
The answer on your question can be only subjective. So I explain how I personally understand the problem and give me recommendation.
In my opinion the data with 2-3 row and 3-4 column can be displayed in HTML table without usage any plugin. The data you display for the user the more important will be that the user will be able to grasp the information which will be displayed. So I think that the information for example have to be good formatted and marked with colors and icons for example. This with help to grasp information from probably 10 rows of data, but not much more. If you just display table with 100 rows or more then you overtax the user. The user will have to analyse the data to get any helpful information from the table. Scrolling of the data makes this not easier.
So I think that one should give the user comfortable or at least convenient interface to sort and to filter the data from the table. The exact interface is mostly the matter of taste. For example the grid can have an additional filter bar
For filtering and even for sorting of the data it's important to have not pure strings, but to be able to distinguish the data types like integer (10 should be after 9 and not between 1 and 2), numbers (correct interpret '.' and ',' inside of numbers), dates (3/20/2012 should be grater as 4/15/2010) and so on. If you just convert HTML table to some grid you will have problems with correct filtering or sorting. Even if you use pure local JavaScript data to display in grid it would be important to have datasource which has some kind of type information and then to create the grid based in the data. In the case you can gives date as JavaScript Date or as ISO 8601 string "2012-03-20" and in the grid display the data corresponds the specified formatter as 3/20/2012 or 20-Mar-2012.
Whether you implement filtering, sorting and paging on the server side or on the client side is not really important for the user who open the page. It's important only that all works quickly enough. The exact choose of the grid plugin, the filtering (with filter toolbar or external controls) and styling of the grid depend on your taste and the project requirements.