Your method is great for SOME applications, but not for the typical Web
search thing. In general:
- If the data does not fit the search criteria any longer, the user
does not want to see it anymore;
- The kind of bookmarks you describe does not help dividing the base
query in pages with the same amount of record, while keeping a
consistent page number -> if there were changes that made many rows
unfit for the current search criteria, it is better that the user
notices that by the abrupt changes in page 4 than that the user has
a page numbered as "4" with data from the current page 2;
- The criteria you propose still makes it necessary to transfer excess
of data (more than the rows needed for the page) out of the database
server;
- Often, the data in cause is not related to just a single table. I am
currently working with pages that join 4 tables or more. You might
think I could simplify this with some pre-processing... but I assure
that it is not so simple.

Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Jason Wharton [mailto:jwharton@...]
> Sent: Tuesday, June 05, 2001 4:46 PM
>
>
> It is also difficult to react to an update of the column values that are
> ordered by.
> Neither way is perfect. I was hoping to avoid the full complexity
> but since
> you are willing to go there I suppose we can whip this horse into a bloody
> pulp.
>
> The times that I use a bookmark in this manner I have means to
> ensure that I
> can always figure out what has happened to it. When a "delete"
> happens It is
> either a change to a record such that it is filtered out of a
> result set or
> if it is actually deleted I always have a separate log table which can be
> referenced. So, I design systems where my bookmarks are always
> around (until
> purged).
>
> If you look in the normal place for a bookmark and don't find it then you
> know to look in the logged place for it. Or, you know to drop off some of
> the filter criteria to see what happened to if. At that point there are
> different ways to get back to the position you wanted earlier. You could
> fall back on a numerical based or just rely upon the values for the
> bookmark.
>
> The easiest way to accomplish this is to have a generation id to
> accompany a
> bookmark. This way you can always find the original record in the
> system. If
> you pull up a bookmark you can check its current generation id
> with the one
> upon fetching it. If they are the same, take full confidence. If they are
> different, then look to your logged table of changes. Triggers and stored
> procedures can be designed to automate this easily. Triggers to
> maintain the
> log table and stored procedures to return a record for a bookmark and
> generation id, whether deleted, updated or still in original condition.
>
> This way the only window for error is during purging of records which
> shouldn't happen very often. Once a year or quarter or something
> like that.
>
> FWIW,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
> ----- Original Message -----
> From: "Peter Morris" <pmorris@...>
> To: <IBDI@yahoogroups.com>
> Sent: Tuesday, June 05, 2001 9:20 AM
> Subject: Re: [IBDI] Subsets
>
>
> > > Bookmark is just my generic way of saying the information necessary to
> > > identify a record on the server. If you have a key to a
> record then you
> > have
> > > the ability to get any information from that record on the
> server-side.
> >
> > Taking your earlier example of deleting records, what would
> then happen if
> > the bookmark-record was deleted ?
> >
> > Pete