[MUD-Dev] Player run reputation system

[Sean Kelly]

From: "J Todd Coleman" <warden at wolfpackstudios.com>
> From: "J C Lawrence" <claw at 2wire.com>

>> 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.

And you start to risk a loss of data integrity, since you're
basically eliminating key relationships.  Still better than a pure
flat-file system but loses out on a lot of the real power of SQL.
Besides, it really is possible to achieve very high performance out
of a normalized database.  And if it's not high enough, just throw
more machines at it and replicate or cluster.  Databases scale quite
easily.  Flat files don't.

> 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.

Really?  With properly designed indexes in the right places, running
queries in stored procedures (since they are pre-compiled, provided
they don't use temporary tables), and an optimized locking scheme,
they can be quite fast.  Binary files may be faster, so long as
you're accessing a single file and there is no contention with other
threads/processes for that same file.  And I really don't see the
need to have things like reporting be time-critical anyway.  It's
game-centric things that matter.  Actually, I would probably
replicate the database to a warehouse and run all my reports off
that.

> 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.

So you're proposing serving a single world from multiple
cross-replicating databases?  I grant that can be difficult.
Distributred transactions are one possibility but that ties the
servers together fairly tightly, so if one goes down you're sunk.
I'm surprised load on a SQL server is so high for an MMORPG that you
would have to do something like this.  A decent server should be
able to handle a couple thousand simultaneous sessions without
breathing hard, and I would probably maintain transaction queues on
the game servers anyway, rather than having my db accesses inline.

I've never seen duping as a problem with a SQL database.  You're not
copying items between players on the SQL server, you're altering
their associations.  If everything crashes, when the server comes
back up you still only have one instance of everything... it just
may be that the transaction will never have occurred.

If you want another alternative, there are object databases.  They
stink for dynamic querying but are excellent as a highspeed
middleware cache.  You could funnel everything through this and let
it trickle updates into the SQL server as it will.  I don't know
whether it would be worth the extra development cost, but it might
be worth experimenting with.

Sean

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev