Hi
I'm catching up on the list so I am a bit late
entering this too. This may have been covered.....
I also remember the fine print on sorted chains.
Fields following the sort item are included in the
sort when INSERTING. When doing a DBUNLOAD/DBLOAD only
the sort field is used in the sort. Never could figure
why IMAGE behaved inconsistently between the insert
and the reload process. Anyone know?
This means that:
a) you should only have one field that includes the
date and time.
b) your sort field should be the last field in the
entry.
c) if it is not the last field then you can not rely
on a dbunload/dbload restoring a sorted chain into the
original sequence
I prefer to use OMNIDEX for IMSAM for determining the
sequence of datasets. You can have multiple items in
the sorted key and get consistent results. You can
also
avoid IMAGE chains altogether and just deal with
detail datasets.
Have not used IMAGE BTREEs yet, but I don't like the
sound of the overheads Steve Dirickson refered to. I
wonder how OMNIDEX would handle such a key structure?
Regards
John Edwards
--- Neil Harvey <[log in to unmask]> wrote:
> I'm coming into this thread a little late, but is it
> not true that when
> Image is deciding where to insert a record in a
> sorted chain, it not only
> compares the field containing the declared sort key,
> but if necessary, also
> continues to look at adjacent fields until it finds
> the correct place?
>
> So, you could separate the date and time fields,
> place them adjacent to each
> other, and declare the date as the only sort field.
> Time (and anything else
> following it) would then become part of the position
> algorithm.
>
> I'm sure I'll be corrected if I'm wrong.
>
> Regards
>
> Neil
>
>
> > -----Original Message-----
> > From: Steve Dirickson [SMTP:[log in to unmask]]
> > Sent: Monday, August 09, 1999 5:06 AM
> > To: [log in to unmask]
> > Subject: Re: Image Chain Order
> >
> > > In all of the Image classes I have taught (62),
> I have
> > > maintained that if
> > > you want the chain in chronically sorted
> sequence then it is
> > > best to specify
> > > a time stamp as a sort item (ccyymmddhhmm). This
> costs some
> > > extra disc space
> > > but doesn't rely on any assumed or possibly
> misunderstood
> > sequencing.
> >
> > I definitely agree--but I'd also definitely use
> something more
> > fine-grained than minutes for the sort item.
> Seconds as a minimum,
> > centi- or milli-seconds would be even better.
> >
> > > An added benefit is that with btree retrieval
> one can add a
> > > path on the
> > > time stamp and do a monthly report by using
> DBFIND with an argument
> > of
> > > [log in to unmask]
> >
> > Ouch! If you're going to make such a
> sort-differentiator a search
> > item, break it into pieces; with a search item
> like this
> > (CCYYMMDDHHMM), you'll have thousands (millions?)
> of very
> > short--frequently length one--chains. IOW, the
> number of records in
> > the master set will be within an order of
> magnitude--maybe within a
> > factor of 3--of the number of records in the
> detail set. I'd at least
> > break the search/sort item into two parts, like
> CCYYMMDD and HHMMSSCC
> > (that last 'CC' is centiseconds), and key only the
> CCYYMMDD part.
> > Which should be low cost, since it's virtually
> guaranteed that you
> > already have other CCYYMMDD fields in your
> database that are search
> > items, so the auto master already exists. Of
> course, this is where we
> > start to run into the exists-for-no-good-reason
> limit of 16 paths in a
> > master set....
> >
> > Steve
> >
> >
> > Steve Dirickson WestWin Consulting
> > [log in to unmask] (360) 598-6111
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
|
