Re: turning player_db and match_player into builtins..

• Date: Tue, 24 Sep 1996 07:17:00 PDT
• From:
  "Adams, Charles" <cadams@msgate.litc.lockheed.com>
• Encoding: 36 TEXT

>>>>>
> How does this compare to the trie structure the database currently uses 
for
> the player db?

Hmmm... Trie might be the same as Treive ... Are you Sure, that it does a
Trie? Of course I could be being confused by the serial nature of the
Database, into thinking that it is using a serial list. But if it is already
using a treive technique then the length of the database, has less impact
than the depth of the search tree.
<<<<<

A trie is a tree that stores strings with a node for each letter in the 
string.  Any path down to a leaf node in the trie is equivalent to one key. 
 The leaf nodes store any data associated with the key.  Note that the trie 
data structure in the $generic_db compresses nodes with single children into 
a string.  Individual nodes are stored as properties.

>>>>>
My feeling is the $0:Player_db or some similar object is the actual trie
object, and that the server is simply implimenting serial lists. Eric has
mentioned wanting to develop tables, and light weight objects at the server
level, but some of us are not convinced that it is necessary.
<<<<<

I am.  E_MOO makes extensive use of lightweight objects, one of which is a 
table datatype that at this time, is terribly cumbersome (but it's sure a 
lot faster than $list_utils' alists).  JHM uses "lightweights" heavily in 
its jtext and pronoun sub system.  Both E_MOO and JHM use lists for these 
lightweights to avoid the heavy costs associated with creating objects for 
every bit of data.  Treating them like objects requires either clumsy server 
hacks or a clumsy user interface.
They're not "necessary", but they sure would be convenient.

[rest of stuff about external db's deleted, this is long enough already]

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