[MUD-Dev] Player run reputation system

[J Todd Coleman]

----- Original Message -----
From: "Valerio Santinelli" <tanis at mediacom.it>
To: <mud-dev at kanga.nu>
Sent: Friday, June 29, 2001 2:23 AM
Subject: Re: [MUD-Dev] Player run reputation system

> ----- Original Message -----
> From: "J Todd Coleman" <warden at wolfpackstudios.com>
> Sent: Thursday, June 28, 2001 7:22 PM

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

> I agree that avoiding joins is a plus, but if you're speaking
> about commercial DBRMS like Oracle, this get down to a real little
> loss of performance when using joins.

If you stick with (even somewhat) normalized tables, read
performance can be optimized with indexes.. but then you start to
really hurt your write performance, which makes it pretty tough to
ensure transactional logging.  (In a realtime system any time you
could have 'reads' hitting against data that has a change 'in
queue', you've got a real problem on your hands.)

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

> Binary files are the way to go for fast data access, but the other
> face of the medal is that you're going to have to take care of
> many issues related to backups of large amounts of data, data
> clusterization (if needed) and synchronizatin problems arise.

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

> I'm not experienced with LDAP too, so I cannot say much. This
> issue needs to be looked into deeper, but maybe it could be a good
> choice if it really does what it's supposed to do :)

Well it's used by a number of really large organizations for things
like : HR records, phone databases, account/pwd tracking, etc.  In
theory it should be a workable solution, but I really haven't had
time to look at it in detail.

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