OT : Advice on SQL database design

[Alex Tweedly]

I guess there's a meta-question about "what's a good book/source on SQL 
database design ?"

I am trying to design a database. There is one table which contains, 
let's say, Armed Forces Personnel
  - each row is a different person
  - columns include the obvious .... name, date of birth, ... that are 
common to all
  - there is a column saying which armed force the person is in
       - and then there are additional, DIFFERENT fields depending on 
which one it is


Plan A.
Just add all the additional columns.

But then they're (mostly) empty! Doesn't seem right.

Plan B.
Separate tables for each set of additional data; the 'person' table has 
a column specifying which set of data exists, and then a foreign key 
which is matched to the primary key of the additional table.

e.g.
Person
1 : John Smith : navy : 1
2 : Jim Brown : army : 1

Navy
1 : Can swim 50 yards

Army
1 : Can walk 100 miles carrying a full pack (???)

Plan C.
Separate tables for each additional data set - but the additional tables 
share the primary key with the person table.

e.g.
Person
1 : John Smith : navy
2 : Jim Brown : army

Navy
1 : Can swim 50 yards

Army
2 : Can walk 100 miles carrying a full pack (???)

I hope that explanation was at least half-way understandable :-)

So - any comments about the choice between A, B or C ?
    - or is there answer "D of course ...."

Thanks for any help
-- Alex.