----- Original Message -----
From: "Michael Anderson" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, February 12, 2003 10:25 AM
Subject: [HP3000-L] Skipper for Image and V-Plus


> Hello to all,
> Quick question;

> I am in the process of designing an Image database, for quick day-time
> inquiry, batch updates run at night. Because of this kind of database
> usage, and the fact that it is mainly static historical data, and fast
> retrieval is the number one requirement. I have used lots of paths,
> including sorted paths. So called experts tell me all the time, not to
> used too many paths, and never sorted paths. I disagree with
> unconditional rules,  Like Never! Why is it that Image has sorted paths?
> Like: Lets design in a feature, and tell everyone to avoid it at all
> cost, doh. I understand the overhead, but that's only during
> DBPUT,DBDELETE, right?

The more paths, the more chains to be linked and unlinked in DBPUTs,
DBDELETEs, and CIUPDATE DBUPDATEs. These 'one-time' performance hits must be
weighed off against the overhead of any serial searches, or less efficient
chain searches with discards, that would have to be made, and possibly made
repeatedly, in data retrieval, but which can be avoided by using paths.

Sorted paths have about zero overhead if you are adding records which happen
to sort chronologically, and having the sorted paths ensures that the
sequence can be preserved during database maintenance tasks.

Sorted paths have the performance hit of a backward chain read from end of
chain to point of insertion on each non-chronological insertion. Affects
DBPUTs and CIUPDATE DBUPDATEs which alter search and/or sort keys. But not,
AFAIK, DBDELETEs.

These 'one-time' performance hits must be weighed off against the overhead
of any 'file' sorts that would have to be made, and possibly made
repeatedly, in data retrieval, but which can be avoided by using sorted
chains.

If you can avoid such serial reads and 'file'sorts, want fast retrieval, and
have enough time for the overnight batch updates to run with the extra
overheads as described, what's to worry?

I'd get yourself some better 'experts'.

> Would it be a wiser use of resources if I remove all paths before the
> nightly batch updates, and re-add the paths when the batch updates are
> complete? And of course I am referring to using ADAGER!

I guess a one-time global repathing in Adager would be more efficient than
the individual DBPUTs would have been.... But whether it would be so much
more efficient that depathing and repathing entire would beat out the
(presumably selective) pathing overhead of the night's update data, I would
doubt.

How much data in the database? How much added each night? If you have just
one week's data held there, Adager would have to be seven times more
efficient just to make a global de- and re- pathing *match* one day's
conventional DBwhatevers. And for a year's data, 365.25 times as efficient.

That's a tall order, I suspect, even for Alfredo's finest.....

We now return you to your regular war programming......

(Oh, and I never heard of Skipper, so I can't help you there)

--
Roy Brown

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *