Patrick Dughi writes:
> The advantages of putting the majority of saved objects in an sql
> database are ...well... incredible. Just off the top of my head:
Well written. I'll throw in a few comments...
> 1) Memory for lists.
> > look at board
> --mud does--
> select * from boards where board_num == 1200
> for each row {
> list_board_message_blurb();
> }
> --mud stops--
You actually take a loss here (if you do this for anything but message boards)
Doing this for rooms/characters and whatnot gets very expensive... much better to
load them into memory on boot (or game entry, for characters) and simply fire
back 'update bla' statements as needed.
> 2) Memory for static items.
>
> Sure - things like the motd, or the entire contents of the
> social and message files - things that don't really change - they can all
> be in there. Other global arrays, structures and counters can be held on
> to as well.
... as opposed to saving to file. Like I said, you don't want to issue a query
for every action in the game, much better to load it all to your mud at boot
and update when it changes.
> 3) Triggers.
>
> If you're not familiar with an sql trigger, think of it as a way
> to run specific commands when ever a database object is
> created/altered/examined/deleted. This could be helpful for just general
> case stuff - like updating the total # of levels in a clan each time
> someone gains/looses a level. These are actually pretty powerful,
> equivilent to C++ classes with all variables only reachable through
> accessor methods.
Nice, but then you have to remember to read all values back into the mud
whenever you change something, since you have no idea what triggers updated
what. Usage of trigger/notify combos helps, though. (notify on update/insert
of room/object/character data lets you edit offline and have the mud reload
anything you changed. Don't try editing a live character, though.)
> 4) State
>
> Sure. A database is independant of the mud altogether. If you
> want, you can save all the zone/obj/world/mob/etc info in one table, and
> have an entire other near-duplicate table be the active world. If the mud
> crashes, you load up your active world - the other would be used for zone
> resets, and the like. This means that if you write the correct functions,
> not only could you restore the entire world to the exact state it was in
> the instant before the crash, you could also do things like
> unique/non-saved mobs/objs/etc with no hassle.
>
>
> Now, there are some disadvantages to this as well;
>
> 1) SQL
>
> Not the most difficult language to learn, but it is another one,
> with it's own particular nuances. The exact sql queries and how they work
> changes from db vendor to db vendor. Thanks ever so much for
> vendor-initiated ANSI derivitives, and underlying ambiguities in the
> standards.
It's not bad, and as long as you stick to the basics you don't run into
too many incompatabilites. Vendor differences are in things like n-way unions
and set logic and the various SQL functions they provide... none of which
you need to simply store data.
> 2) Configuration
... fortunatly, if you own your own machine and it uses a modern OS,
it's as simple as a package install... at least, for most flavors of linux
and BSD. Probably solaris as well
> 3) Portability + Releasing
>
> If you ever want to do something like move a stored database
> object to another machine, you'll have an inherent difficulty. Unless
> your other system has both the same version of the same db, AND, the same
> version of the same operating system, no type of archival or backup scheme
> will necessarily work. This means you can't release zones/areas you
actually, that's not true. it's not hard to parse a table into insert commands
as a worst-case scenario... of course, if you change DB types you'll have to
change all your database code to the new type... hence my using a very thin
shim between you and the DB... you only have to rewrite one set of functions
to 'port' to a new backend DB.
> create with much ease. This also means that you can't - for example -
> send a world builder their 'files' for spell checking, offline
> development, or simply if they want a copy in case they move on to another
> mud in the future. You'll have to write code to do this.
Very true, although it has the advantage of letting you do web-based
world editing (which can be very nice, and is simpler to do then building
umpteen billion OLC states.)
> 4) DB usage
>
> Depending on the speed of the computer, it may actually endup
> that you loose more time executing and returning the database queries than
> you save by using the lightning fast lookup and queries in the first
> place. I would bet that this won't be an issue however.
True, which is why you boot from the DB and run from local structures.
I've noticed that a few databases have the ability to do async queries...
I.E. it becomes another socket, but with a different handler. This lets
you fire off an 'update player set hp=5 where id=7210' ... without waiting
on the database to return. So it costs you next to nothing.
As a bonus, coding for that requires you queue outgoing SQL statements
(so to only have one 'in flight' at any given time) so you can optimize
your updates. (if bob got hit for 10 hp then another 5 before the first
update went out, send an update for -15)
> Again, thats off the top of my head, I'm sure there's alot of
> other reasons for and vs database dependancy but i'm sorta tired, and I
> need to go get a cake from the oven. Doesn't everyone make cake at 3:30
> am?
Nope. I usually bake cookies.
--Dan
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT