[MUD-Dev] Player run reputation system

J Todd Coleman warden at wolfpackstudios.com
Thu Jun 28 12:22:16 CEST 2001


----- Original Message -----
From: "J C Lawrence" <claw at 2wire.com>
To: <mud-dev at kanga.nu>
Sent: Wednesday, June 27, 2001 9:25 PM
Subject: Re: [MUD-Dev] Player run reputation system

> The computational load is actually fairly trivial.  At the SQL end
> its 3 - 4 joins per entry, and you mostly need to do that during
> rendering, not during entry.

That would depend entirely on how the tables were organized --
typically it's best to avoid joins at all cost, even with indexed
tables.  When you're going for read optimization, throw all that
"normalize to the highest degree possible" crap out the window.
Denormalize as much as possible, and you eliminate the need for
table joins.  The downside, of course, is that you waste a lot of
space with repeated data, but thats often a much more trivial
concern than performance when you have a huge number of concurrent
users.

SQL databases are great for organization later down the line (you
get online editing, reporting and instant queries of your user DB
almost instantaneously if you set it up correctly) but you still
take a dramatic speed hit over using binary files. For this reason
we're likely going to set up ours in more of a "data warehouse"
approach, where the runtime files are stored on binary and pushed up
to a "query database" into a handful of fully denormalized tables
for help with speedy query/reporting.  Alternatively, I'm starting
to look at the LDAP stuff to see if it's a viable alternative -- it
certainly has promise, in that 1) it's fast, because the entire
database is kept in memory and 2) it's specifically made for
distributed server systems, so the whole "synchronization" issue
(that leads to lost records, duping, and a plethora of other issues)
is to a large degree resolved... theoretically.  Plus it isn't that
expensive (in fact you get a 200k record version license when you
buy Solaris.)  Like I said, though, I'm not as familiar with it, so
it may have some huge holes I'm not aware of.

Strangely, the best performance would probably come out of using a
hierarchical dataset, like VSAM or ISAM (or Unidata).. but that's
crazy cobol stuff, so no mud developer would touch it with a 10ft
pole. (and to be honest, I don't really blame them.)

J Todd Coleman, "Warden"
Wolfpack Studios, Inc - Shadowbane
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list