On 14 May 2007 05:29:59 -0700, Lo'oris <looris@gmail.com> wrote:

>oh, stupid NULLs. i guess i shouldn't make assumptions.

There is no problem with assumptions, provided you verify them
carefully !

>two, because, even if they ideally should be only a single table, the
>first one will be used MUCH more than the second one, so having them
>separate should increase speed when accessing the first one, i guess.

Likely, especially if you have only fixed-length types in the stats
table. But it depends also : you might think that 15 stats values are
a lot, but if they all are TINYINTs, they don't take much place, and
if you have a few VARCHAR(50) for the names and description of a
player, the 15 stats are finally not that much (they take as much
space as the name if the name is Albert Einstein).

I don't know exactly what will be in your player_per_match table, but
i guess you will have strings. Do the players choose their own player
name ? Do they change every time ?

By the way, why not a 3 table design : player / match / stats, stats
also playing the role of a many to many link between player and match
? Do you really need that player_per_match table, without the stats in
it ?