Glenn Cole writes:
> Wirt writes:
>
> > I drop and add all of the b-tree indexes to our databases on a regular
> > basis.
>
> Why?
The b-trees are regularly added and dropped for two reasons -- neither one of
which would be normal in a production environment. The simpler of the two
reasons is that one of the HP3000s that is being used as a development
environment is also used as a production machine to create demonstration
tapes to send to prospective customers -- and we can't send out an
incompatible copy of the demonstration IMAGE databases that ride along on the
tape.
The more complex of the reasons is that QueryCalc, like Adager, SuprTool and
all other well-crafted software on the HP3000, must work against every
different version of IMAGE that they encounter, on both Classic and RISC
machines. All of these products accomplish this by taking measurements of the
operating systems and the versions of IMAGE, KSAM, etc. that they find in
place and automatically adapting themselves to whatever capabilities exist on
the current machine.
Adding and dropping the b-trees is simply part of that testing.
On a related subject, I've enclosed below a printout of the schema that
QueryCalc generates for a single dataset. As many of you have heard me say,
what we're trying to do with QueryCalc is turn the HP3000 into a Macintosh,
to remove all of the unnecessary complexity of a mainframe device, and let
business people (office managers, bookkeepers, accountants, CFOs, CEOs, and
summer hires stuck in the basement) have full and complete access to the
their data -- without being swamped by unnecessary technical detail. No other
machine out there is as well equipped to become a true "personal mainframe"
as the HP3000, operated day-after-day, reliably, with no large data
processing staff on-site.
The mental model that we preach to every one of users, CEO and DP manager
alike, is to think of IMAGE as a set of steel filing cabinets, the detail
datasets being the large steel drawers, marked with little white cards on the
front, saying things such as JOBS, INVOICES, CHECKS, etc., and the master
datasets as being 3x5 indexing cards that sit on top of the filing cabinets.
While we actually do explain how b-trees work to everyone, most people simply
sit there and politely listen. It's all interesting, of course, in the same
way that it's interesting for you to know how the electrical capacitance
changes in your car engine's cylinders as the piston nears the top of its
stroke, but that's all it is: interesting. Most people merely want to know
how the feature affects their work and how might they take advantage of it.
The important take-home lesson of b-trees is that you no longer need to know
the search value in IMAGE in its entirety in order to create a high-speed,
indexed search. While we debated for some time what to call the new,
b-tree-enhanced search items, we eventually settled on labeling them as
"full" and "simple" search items, with "simple" being a standard, hashed
IMAGE search item, where you have to know the value in its entirety, and a
"full search" being one that you can ask for either a high-speed range or a
generic search (if you know the beginning of the value -- and it's a text
field).
In the dataset below, at the time this snapshot was taken, some of the
masters had b-trees attached and some didn't. We felt these two terms best
described the value of the new indexes.
===================================
NAMELIST [detail set]
ITEMS DATA TYPE
IDNUMBER I1 [num] [full search item]
FNAME X12 [text]
LNAME X18 [text] [full search item]
PNAME X18 [text] [full search item]
COMPANY X30 [text]
ADDRESS1 X30 [text]
ADDRESS2 X30 [text]
CITY X20 [text]
STATE X2 [text] [simple search item]
ZIP X10 [text]
COUNTRY X20 [text] [simple search item]
PHONE X20 [text]
FAX X20 [text]
ENTRYDATE X8 [text]
===================================
Wirt Atmar
|
