[MUD-Dev] Re: Databases

[Kevin Littlejohn]

>>> "Laurent Bossavit" wrote
> [On databases in general]
> 
> I wouldn't use MySQL - the fastest SQL database around - for a MUD. 
> It's optimized for ultra-frequent fetches of small to medium large 
> chunks of information; our databases services 50 queries/sec and 

Hrm.  I'd have said that ultra-frequent fetches of small to medium chunks
of info is pretty much exactly where a mud sits.  Of course, that depends
really heavily on _what_ you're using a database for.  If you're using it
instead of file storage for characters, then it probably doesn't matter
_what_ you use.  If you're using it to hold all your live game data, then
things get a bit trickier...

MySQL seems to work out nicely for us - admittedly, I've yet to see a
strain on the thing, but from what I've seen, I've got no concerns there.
What it _does_ lack, however, are transactions, and sub-selects - both of
which would help considerably in design ;)

Others:  gadfly (python-based, if you know the layout of your tables it's
probably fastest, but equates out to having all data in memory at all times),
mSQL (dunno, haven't looked at it for a long time), Oracle (overblown,
slower than MySQL, but by $DIETY it does everything, including 'connected
by', which would be a _joy_ to use - provides for object hierarchies really
nicely), PostgreSQL (which _does_ look nice, and has some nifty tricks that
may help on the OO side...  But which I couldn't fathom large object/blob
support for, so I gave up early).  The list goes on, of course... ;)

> about a quarter of a gigabyte. It all fits on one (admittedly beefed 
> up) machine. But I wouldn't use any of the "big" databases either; 
> they are optimized to scale to terabytes of data, with robustness and 
> consistency of the data given much higher priority than performance.

Again, I suspect it depends on what you're aiming for.  Transaction support
under Oracle would be a godsend - kiss locking issues goodbye, pretty much,
if you plan things out right data consistency is a non-issue.  Also, Oracle
does nice distributed database tricks - if you're willing to spend the
dollars for your mud ;)

> Fact is, I wouldn't consider using an SQL database for a M* type 
> application; it's too much of a pain to map SQL records to the object 
> oriented data used in most such software. My wish would be for a 

This, I almost agree with ;)  I have a layer set aside in Moebius that
maps SQL to OO, and it's a right pain.  In addition, the quickest way to do
some things is no longer the obvious way - when the rest of your
programming world is OO-based, to suddenly discover that queries across the
mud (to find a particular type of item, for example) can be done much
quicker if you acknowledge the underlying non-OO-ness of the data store -
well, it throws an abstract spanner in the abstract works, if that makes
sense ;)

> native XML data store, with the ease of use and top-notch performance 
> of MySQL, and a query language as useful and usable as SQL. This 
> would be perfect for a MUD, and in fact many other types of 
> applications - with a good XML database you don't need SQL, you don't 
> need an OODBMS (XML-Data bindings do the OO part, the data store does 
> the dirty work), you don't need much of anything. Unfortunately there 
> isn't such a thing out there yet.

There _are_ OO-specific databases out there - Oracle have recently (with
8i, I think) started adding an OO layer to their stuff, so you can treat
things as 'objects' inside the db, and let oracle work out how to map that
best.  That's hackish, I suspect, but presumably works into their XML
support as well.  Would not the OODBMS's of this world put you a good way
toward this?

My attitude is still that databases do some things really well - storing
data, and for relationals, working out what links to what - and while they
may not be _ideal_ for muds, the chance of any given mud thrashing any
given database is still pretty slim at the moment.  It seems as though db's
are generally a win over flat text files, so even if you use them as a
strange sort of disk space, they're a win - let alone abstracting and
playing with some of the other tricks they'd allow.

> 
> Sigh.

What he said ;)

KevinL



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev