# turning player_db and match_player into builtins..

"Adams, Charles" (cadams@msgate.litc.lockheed.com)
Mon, 23 Sep 1996 06:44:00 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    >>>>>
    [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.