Re: How do I browse a database ?

From: R.Wieser <address_at_not.available>
Date: Sat, 10 Aug 2019 18:00:12 +0200
Message-ID: <qimpmj$16eg$1_at_gioia.aioe.org>


Jerry,

> Well, you've already ruled out the typical way it's done in MySQL - with
> "OFFSET" and "LIMIT".

[Quoted] I did not rule it out - far from it actually - but as I'm told that that is /not/ the way to go (and I do understand the reasoning behind it) I'm (trying to) explore other methods.

>> Currently I've got nothing ...

[Quoted] By the way: I ment that in regard to a possible method (possibly) unique to MySQL you seemed to be hinting at.

> The other problem you run into in creating a temporary table with just
> unique keys ...

[Quoted] Thats another way. But as I started my quest on a low-resource machine (256 MByte of memory) which could easily get exhausted by a "just the unique keys" temporary table I decided that I should not yet stop looking.

> ...that if the database changes (rows added/deleted/updated) your
> temporary table is now out of date

[Quoted] While mulling over the possibilities I realized that too, and noted it in the "con" column for that method. But here missing record would be visible, as a request for the record with a specific key cannot be completed (and the viewer displays an empty line).

A similar problem exists for the OFFSET method, being that records disappearing below that "offset" causes the retrieval to "jump over" records that have not been displayed yet (but this happens without any kind of signalling)

> What you do is add the primary key as the final sort parameter

[Quoted] I'm not sure how, in a temporary database containing just the unique keys of the actual database, there should be 1) sorting 2) more than /only/ an unique key (record index?) of that temporary database as a parameter ...

(confusing to have two "unique keys" to talk about. I hope the above is clear in which one is what.)

Regards,
Rudy Wieser Received on Sat Aug 10 2019 - 18:00:12 CEST

Original text of this message