Re: turning player_db and match_player into builtins..

• Date: Mon, 23 Sep 1996 06:44:00 PDT
• From:
  "Adams, Charles" <cadams@msgate.litc.lockheed.com>
• Encoding: 43 TEXT

>>>>>
[snip]
One use for B+Tree, or even B-Tree or Treive technology, is that it speeds
the access to a database by allowing the database to be accessed utilizing
random access capabilities rather than using serial list capabilities. you
simply need a little overhead to handle the B+Tree, and you cut out the
length consideration to response. An even better alternative is the extended
Hashing functions that allow you to do away with most of the actual overhead
as well, but while I understand the requirements for the B+tree or treive
I don't necessarily understand the same requirements when extended hashing
is involved.

In a while, I will begin to work on Mod1 of newcore, in which I intend to
impliment a B+TREE technology as a "DATABASE in DB". I believe that this
technology, even implimented on the servers serial-list capabilities of
1.7.7 and 1.7.8p4 vintage will be a significant addition to the MOO base.
<<<<<

How does this compare to the trie structure the database currently uses for 
the player db?    As a matter of fact, tries are perfect for string prefix 
match comparison, which might be why they chose that structure when building 
lambdacore's $player_db.  You never mention the word "trie" once, and go on 
quite a bit about completely unrelated subjects such as threads.

>>>>>
One of the reasons that I am building this base, below the user-level, is
to allow greater flexibility at the Userlevel, when I get there. In Mod0,
I created basic tourist objects that essentially were glued in place, simply
to allow people to "Look around" at the minimum architecture. In Mod1 I will
make it possible for there to be a more rich environment for them to move
around in, because the environment itself can be extended from a
Database-inDB technology.
<<<<<

Lemme get this straight:  It's wired into the server for greater 
flexibility?

I'd like to see tables in-server as well, but I fail to see where all this 
talk about B-trees or B+ trees is headed.  I'd also like to see tables that 
could be tied to an external dbm (ala perl5's 'tie' function) but I'm not 
holding my breath.

• Re: turning player_db and match_player into builtins..
• From: Graeme Smith <grysmith@freenet.edmonton.ab.ca>

• Prev: Re: turning player_db and match_player into builtins..
• Next: Re: turning player_db and match_player into builtins..
• Index: MOO-cows
• Thread: MOO-cows