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