Christopher Browne <cbbrowne@acm.org> writes:
> A long time ago, in a galaxy far, far away, Typing80wpm@aol.com wrote:
>> I must say one intereting thing. When I downloaded the trial version
>> from TheKompany, and asked it to browse a test file in PGSql which I
>> loaded with 250,000 rows, it started to read them, and read for a
>> long long time (as MSAccess does), but the seemed to get stuck,
>> whereas MSAccess is able to browse the entire file. I must
>> experiment more with the demo version from theKompany, and also with
>> this free version from the site you gave me.
>
> This sort of problem is characteristic of the use of "array" objects
> in graphical toolkits.
>
> Suppose you're populating something with 250K rows, perhaps with a
> dozen fields per row. In such a case, the toolkit is slinging around
> 3-4 million objects, and having to evaluate which of them are visible
> on screen at any given time.
>
> _Any_ kind of inefficiency in the library, or in the use of the
> library, can easily lead to rendering turning out really, really
> badly.
I think I took this down something of the wrong road, in explaining
why this turns out badly.
The other "fork" in the road has a big sign marked "Yes, pulling all
the data into the GUI turns out badly. That's why you shouldn't do
that!!!"
If there are 250K rows, that's probably way more than any user can
cope with working with at any given moment.
If the database grows to have 2.5 million entries, or 25 million
entries, or some billions of entries, it is absolutely the wrong idea
to try to pull it all out and stuff it into some GUI objects.
If the data won't all fit on the screen, you probably ought to wonder
if maybe you need to think about a better way to get at it...
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/sap.html
Rules of the Evil Overlord #78. "I will not tell my Legions of Terror
"And he must be taken alive!" The command will be: ``And try to take
him alive if it is reasonably practical.''"
<http://www.eviloverlord.com/>
