Repeater for many lines

Asked

Viewed 93 times

2

I have a problem in an application I am developing where I have a database with approximately 20 million lines.

The problem is that the user wants to see all these 20 million lines on a single screen, even if the scroll bar gets huge, formerly this table was exported to Excel and he used Excel for this but as in Excel there is the limitation of approximately 1 million lines they want to be developed this application.

Any suggestions on how to do this so you don’t miss out on performance?

  • since you mentioned Repeater, it wouldn’t be Webforms?

  • there is a similar Repeater to webForms for winforms, but this question was in case to change the topic? if you have put in wrong topical apologies and I can remove this excerpt without problems

  • No, if it were Webforms would suggest using an Infinity Scroll. in any case you can try something similar to winForms.

2 answers

3

Let the user know that it is not possible to load or display "all on a single screen".

Let’s get to the numbers

Making a rough estimate, if each record in the database occupied an average of 512 bytes, it would need approximately 9.5 Gigabytes of memory only to store the data on that screen.

Note that much more memory would be needed to render these elements into some visual component. Of course it is possible to use some pagination technique in memory, but still the performance would be painful.

Add to that the need to transfer almost 10GB over the network to load the screen completely. This would be almost equivalent to downloading a double-sided DVD!

Viable options

What would be possible is simulate or give the impression that all the data is there.

You can use some asynchronous paging scheme where the user selects the page or some filter that limits the data he wants to view and then you only upload enough records to fill the screen.

If your query is efficient, the screen will load almost immediately, but there will be a small delay between each navigation. Something much more tolerable.

1

I think the question would be neither of performance, but of usability.

Generally, it is more worthwhile to implement a good search engine than to do what you are proposing.

Compromised usability

Imagine a 1000 pixels high scrollbar (almost the height of a monitor 1600 x 1200). This means that for every pointing pixel, there will be 20.000.000 / 1.000 records => 20.000 records per pixel.

It turns out that when you scroll down to the records, you’re going to go to the first of that 20,000 sequence, you’re always going to show how many fit on the screen, and the rest of the 20,000 is hidden... here comes the question: How are you going to access the rest of the 20,000 records? With the keyboard arrow? With the mouse scroll ball? Page down and page up keys. This is unviable. What’s more, hunting pixels on the scroll bar is already something counterproductive for conversation starters.

Alternative:

Come up with something clever, something that will be really useful to whoever asked for it. User is usually like this, not sure what he wants... he thinks: I need to have access to any record, so I put all records on the same screen. He doesn’t think, I need access to any record, so I need an effective way to get to them, so I need a search engine that meets my needs.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.