Nancy;

   Originally it was "binary", two branches at each branch point.   The
performance sucked.  Then there was the discovery of the multi-way B-tree.
The speed is much faster.  Roughly, the branching is 50 to 1 as opposed to 2
to 1 for binary trees.  Also the data layer with the multi-way b-tree is
easier to walk sequentially than having to do a tree climb.

    Chris
.
----- Original Message -----
From: "Nancy Anthracite" <[EMAIL PROTECTED]>
To: <hardhats-members@lists.sourceforge.net>
Sent: Tuesday, August 23, 2005 6:05 PM
Subject: Re: [Hardhats-members] Re: Is $$GTF~%ZISH() binary friendly?


> B, I believe, is for Binary.
>
> On Tuesday 23 August 2005 06:11 pm, Gregory Woodhouse wrote:
> > I think Kevin was asking whether or not strings are null terminated.
> > I know nothing about the GT.M source, but as a general sort answer:
> > Databases don't typically store data in a "packed" format (like the
> > run-time heap), but instead storage is allocated in fixed size
> > chunks, which are then typically organized into a structure called a
> > B-tree. This makes it possible to add and delete records (nodes) or
> > to modify the size of an existing node without having to drastically
> > modify the entire structure. (So far as I know, the origin of the
> > term B-tree is unknown, but I like to think of them as "bushy" trees.)
> >
> > ===
> > Gregory Woodhouse
> > [EMAIL PROTECTED]
> >
> > "Design quality doesn't ensure success, but design failure can ensure
> > failure."
> >
> > --Kent Beck
> >
> > On Aug 23, 2005, at 2:54 PM, K.S. Bhaskar wrote:
> > > Probably not of much value to ask unless you are a GT.M internals
> > > developer - details are in the source code.  As a gross simplification
> > > (along the lines of saying that living things are made up of cells),
> > > GT.M stores the length and actual value of each string.  But there are
> > > all sorts of optimizations, including key compression when stored
> > > in the
> > > database.
> > >
> > > -- Bhaskar
> > >
> > > On Tue, 2005-08-23 at 16:22 -0500, Kevin Toppenberg wrote:
> > >> So Bhaskar, is of any value to ask how the data is stored behind the
> > >> scenes?  I was worried that the strings were null-terminated etc and
> > >> that there might be some binary data that would crash GT.M. when
> > >> storing is in a global value.
> > >>
> > >> I'm glad to hear that is not the case.
> > >>
> > >> Kevin
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
> > Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Hardhats-members mailing list
> > Hardhats-members@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/hardhats-members
>
> --
> Nancy Anthracite
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Hardhats-members mailing list
> Hardhats-members@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hardhats-members
>
>




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members

Reply via email to