Re: Circle 4.x wish list

From: Axel Trocha (axel@trocha.com)
Date: 11/25/02


On Mon, Nov 25, 2002 at 11:49:01AM -0500, Mysidia wrote:
> > Besides that, it does not matter if it is MySQL or Postgres, since any
> > external database would just add too much unneeded overhead. I do not even
> > want to imagine to access a database in some time-critical heartbeat()
> > function (e.g. mobact.c)
>
> That is by no means clear.  Some databases would indeed add too
> much overhead to be accessed in time-critical functions, but most
> databases are fast enough for this.

Well, sure they might be fast enough, but what would be the gain? I have done
my share of tests in implementing databases into diku-gamma code, but then
after coding some days I ended up caching data 'on MUD side' anyways, using
just those structures which I wanted to eliminate at the beginning.

I agree that in theory a database would be a more clean approach. For
instance you would not have that renumbering issue when adding new
rooms/mobs/objs or the vnum->rnum resolution could be handled a lot more
nicely than making a binary search everytime.

But practially I still think that the current approach is the most simple
and efficient one. I would be happy to be proven wrong, but in the meanwhile
I do not see why the source should be bloated or overhead being added. Well,
maybe I have just grown too old and still think its a 8086 I am coding on :)

We do use a database for boards, mail and access-levels with more to come,
but that will only be stuff which won't be accessed a lot. Storing player,
room, mobile and object prototypes would have been a nice use for databases
too, but we decided to use single XML files for those, just for the sake
of simplicity and support.

Axel

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   | Newbie List:  http://groups.yahoo.com/group/circle-newbies/   |
   +---------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 06/25/03 PDT