> > What avantages does sql have over regular world/player files. I
> remeber a > post on CeramicMouse about how SQL wouldn't work right in a
> MUD > atmosphere. But for some reason I am stuborn and probally will try
> to add > SQL support to my mud. Any one want to help takle this huge
> thing.
The advantages of putting the majority of saved objects in an sql
database are ...well... incredible. Just off the top of my head:
1) Memory for lists.
Allocating memory for lists would be removed altogether. By this
I mean things like pre-parsing files for easier random access later.
Because any normalized db will allow you immediate access based on a very
small sample of unique information. This would affect anything from
boards (especially if you have the dynamic board v2.x, they get LARGE), to
houses, to the player table, clans if you have em, etc. Suddenly, you
just can return a well worded dynamic sql query (or a statically generated
one too, I suppose to improve instruction prefetch optimization)...
example:
> look at board
--mud does--
select * from boards where board_num == 1200
for each row {
list_board_message_blurb();
}
--mud stops--
Etc.
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.
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.
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.
5) No rewrites
Much like ascii pfiles, there is very little involved in ALTERing
a table entry. Say you want to add a clan structure to each player file.
Bang-snap, it's done in an instant. No pwipes.
6) No problems with conversions.
Say you've decided that your ac is going to go from -1000 to 1000
instead of -100 to 100. Normally you'd have to either write a function to
load all of your objects, modify the correct stat, and then save them.
The alternatives consist of writing scripts to traverse all files, or
doing it by hand. With an sql database though, you can fire off a single
function which can run through the entire system and convert and save
pretty much on the fly. If you save 'state' as in #4, you can also do an
instant online conversion for game players as well!
7) reliability.
Lets face it, ascii pfiles are simply not 100% reliable.
Especially when you allow things like descs or other player entered data
in to your weak self-defining file (weak because it has no verification
ability, like hypertext does). Binary files are reliable, but tense. If
you change something you can screw them all up. Databases though don't
have to deal with this. The only sort of 'error' you can make is in your
data entry, pretty much.
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.
2) Configuration
Usually database configuration is no small chore. If a database
comes with your system setup, usually it has it's own owner. Sometimes
they need to run daemons, or even (depending on your db type + setup)
access ports < 1024. This means you have to learn how to configure and
setup your db. Even if you're not the one doing it, it's really still up
to you to tell them how to do it, and to trouble shoot. This is really
the worst part about most databases - pain in the ass to get going, even
if they're mainly trouble-free from then on.
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
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.
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.
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?
PjD
+------------------------------------------------------------+
| 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