>case 1) a table with many fields for storing some data, usually most
>of them will be NULL because they are (and will ever be) unsused
>
>case 2) a table with just 3 fields, but many entries, one for each
>field i'd have used (not null) in case 1.

This is problematical if the types of the fields aren't all the
same.

Consider also: case 3) a bunch of tables with 2 fields, the primary
key, and the value of some column (not null). From case (1), you
have a fixed list of these attributes. So use one table for each.
If a value is NULL, leave out an entry in that table.

This potentially costs disk space for storing repetitions of the
primary key (and indexes), but you don't store anything for NULL
values.

Incidentally, you might consider whether values of NULL or 0 or
something else is more appropriate. NULL might correspond to the
stats of a game which hasn't been played yet; 0 might correspond
to the stats of a game that is completed but without the player,
say, batting in any runs. The difference might be significant if
you want to use avg(rbi.score) to compute overall stats, where
values of 0 (completed games) count in the average and values of
NULL (unplayed-yet games) shouldn't.


>which is better, in general?

Which is better, Pepsi, rat poison, condoms, or beer? It depends on
whether you're thirsty, rat-infested, horny, or sober.