Top Mud Sites Forum - View Single Post

eiz · 03-25-2005, 07:43 AM

"Flat file" is generally used to refer to sequential, plain text storage. It's not a bad choice if your data set is small enough to fit in memory and you use some sort of rational encoding (e.g. xml, s-exps, yaml).

With that said, my storage method of choice for a MUD is an object-oriented database. Some MUD codebases are specifically designed around this (e.g. ColdC), but odds are there is an OODBMS available in your language of choice. Most C++ OODBMSes are commercial products, although there is GOODS and Brian Lindahl's upcoming MudDB, which may actually be completed sometime in this century. However, if you're flexible on language choice you have some options. In particular, I'm thinking of the .

Basically, how it works is you make classes that inherit persistent.Persistent. Then you simply make sure these objects are reachable from a 'root object'. ZODB then handles persistence and caching transparently. You just begin a transaction, modify your objects, and commit. For indexing, you create a persistent btree object (OOBTree) and stick your objects in it. It's probably the simplest possible way to store some data.

03-25-2005, 07:43 AM	#2
eiz New Member Join Date: Feb 2005 Posts: 25	"Flat file" is generally used to refer to sequential, plain text storage. It's not a bad choice if your data set is small enough to fit in memory and you use some sort of rational encoding (e.g. xml, s-exps, yaml). With that said, my storage method of choice for a MUD is an object-oriented database. Some MUD codebases are specifically designed around this (e.g. ColdC), but odds are there is an OODBMS available in your language of choice. Most C++ OODBMSes are commercial products, although there is GOODS and Brian Lindahl's upcoming MudDB, which may actually be completed sometime in this century. However, if you're flexible on language choice you have some options. In particular, I'm thinking of the . Basically, how it works is you make classes that inherit persistent.Persistent. Then you simply make sure these objects are reachable from a 'root object'. ZODB then handles persistence and caching transparently. You just begin a transaction, modify your objects, and commit. For indexing, you create a persistent btree object (OOBTree) and stick your objects in it. It's probably the simplest possible way to store some data.