[MUD-Dev] Player run reputation system
McManus
McManus
Tue Jul 3 12:33:16 CEST 2001
-----Original Message-----
From: J Todd Coleman [mailto:warden at wolfpackstudios.com]
Sent: Tuesday, July 03, 2001 8:58 AM
To: mud-dev at kanga.nu
Subject: Re: [MUD-Dev] Player run reputation system
> I'd also be curious to see what happens when you add more than two
> tables to your test case. What happens to the cost hit when you
> include a third table, or a fourth? Is it still 2x the time, or
> does the multiplier continue to increase as well?
Hmm time for my second foray into saying something. :) I try to keep
my mouth shut on things I'm still learning on, but this thread has
(at last Whoo! *cough*) wandered into territory I can actually say
something meaningful about.
I'm a database programmer / DBA of some years experience. I have to
say my little warning signals go off whenever anyone is thinking of
doing full table joins. IMO, the number of situations that a full
table join is appropriate is on the order of how many times GOTO is
a good programming command. :)
If you have a situation where you think you need full table joins
(other than for small, cross reference type tables), you are
probably missing the chance to cut down on the select set with a
where clause. As soon as you can use a where clause you can be using
those niftly little things called indexes.
Now, mind you, I fully agree that a transactional database and a
reporting database have intrinsically different indexing needs. You
need to decide which is the most important purpose of your database,
and index accordingly. It isn't unusual to have a transactionally
indexed database, with a data dump on a regular basis to a
denormalized reporting indexed database. But I still stand by my
opinion that full table joins are almost always not needed. There is
almost always some metric you can use to limit your data set -
whether that be by time (just the last year), or what have you.
_______________________________________________
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