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.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
