Re: "index" efficiency... any help or ideas?
From: Alex McDonald (alex_mcd_at_btopenworld.com)
Date: 12/15/03
- Next message: Ross Simpson: "Re: A Parable of Two Carpenters"
- Previous message: Beth: "Re: Review of AoA & God's Name"
- In reply to: Bx. C: "Re: "index" efficiency... any help or ideas?"
- Next in thread: Nathan C. Baker: "Re: "index" efficiency... any help or ideas?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 15 Dec 2003 20:13:05 +0000 (UTC)
"Bx. C" <null@the.void> wrote in message
news:bEkDb.5$Xd6.1@bignews6.bellsouth.net...
===snipped
Do a search on "b trees" in google. Some of the papers I found might help
you refine your algorithm. B trees are powerful data structures; of some
significance to your problem is a technique called "front end key
compression" that doesn't require the storing of the entire key in each of
the subtrees. In other words, if I got to this part of the tree due to my
search key starting ABCDEF... then I don't need to store ABCDEF in the
strings in this part of the tree; all the entries in this subtree start with
ABCDEF. I _think_ this may be what you're trying to do. They're also pretty
good at allowing insertions/deletions without becoming very unbalanced.
Again, they're more suited to disk file systems. Grey bearded geek note; the
IBM VSAM access method (file system) uses B trees for its indices.
-- Regards Alex McDonald
- Next message: Ross Simpson: "Re: A Parable of Two Carpenters"
- Previous message: Beth: "Re: Review of AoA & God's Name"
- In reply to: Bx. C: "Re: "index" efficiency... any help or ideas?"
- Next in thread: Nathan C. Baker: "Re: "index" efficiency... any help or ideas?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|