For a future implementation in our software we are facing the issue of large amounts of data.

The main question in this situation is that how do we handle and display the data. because the data also needs to be editable ( single row and batch update).

Because of perfomance issues we cannot show all the information but we want to be able to edit all information in 1 go.

Right now we have a pagination component that displays the total results retrieved and the total results displayed.


If multiple entries can be added together, would you show them as a single row. Or keep them in multiple rows.

To give some more information on what we currently are using. This is the wy we currently use grids.

enter image description here


We are going to retrieve the availability within a hotel for a group of visitors. The amount of data we are going to retrieve is determined by multiple factors.

Date * Roomtype (range from 1 to 5) * price * dates before * dates after.

Within the implementation we are going to get it could easyly give the following result.

180 days * 2 roomtypes * 2 prices = 720 rows with results

2 Answers 2


I'd suggest using a grid-based structure that fits your stack. That way you should be able to implement grouping / filtering functionality to help the user find the information that is relevant for the user's specific task.

Where I work it't not all too common to display grids with more than a few thousand rows and 10+ columns.

What is very important to keep in mind when displaying large sets of data is to make grouping clear for the user so that information is clearly distinguishable. That way it's easier for a user to find the information that he needs to reach his goals.

The main object for a list / grid is to display the data in a way that makes it easy for the user to find what he needs to find using as little processing as possible.

You shouldn't focus on displaying everything on a single page of the grid, but rather limit the user to a the top items that would be relevant for a core-user and then let the users that need further information use whatever functionality you decide to implement to find any further information (like paging, grouping, filtering, searching etc).

Again, the less information you display the more you can put the user's focus on the functionality of the grid. It's important to keep in mind that a human-being only has a limited attention-span and that we easily get confused / distressed. What this means is that if you use a system for the first time and get faced with a grid of 1000 rows each with 10 columns you might not notice that the grid allows you to search for a specific key in the grid and might feel discouraged to finish your assignment of finding "John Doe who lives in Arkansas" - which will give you a horrible experience of the system.

If you instead are presented with a system that shows 10 rows each with 10 columns that all represent relevant information you might find it easier to find that search-button simply due to the fact that you have less information to actively process.


It depends on this: Why would you want to display multiple entries on separate rows? Does it hold any significant value of displaying them on different rows? If yes, then I'd suggest displaying them on separate rows.

However, it's difficult to say if it would be as there is no context to what sort of data you are going to display. If we knew more it would make it easier.

Without knowing what information is relevant to show on your grid I'd suggest considering using detail tables or something similar where you can open a more detailed table of a specific row that might display further detailed information. For instance it might not be relevant for a user to see who booked the room, what company is using it, the policy status etc.

Again, it's difficult to say what is relevant to display and what isn't relevant as the requirements you have for the application might be completely different from what I would want to display on it from my perspective.


I see you use Datatables. You also said, "the data needs to be editable (single row and batch update)". In this case, you already decided what type of design you will have for the edit functionality and for the table.

If you want to reconsider this, please read Responsive Data Tables | CSS Tricks and Components– Data tables | Material Design. You can edit the info even it is displayed on multiple rows (inline text editing or with a small edit dialog).

For the number of rows on the page, pagination sounds good to me.

Also, check the examples from Material Design Blog:

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.