Jeff is spot on (I'm not British, I just love saying that!).

I'll elaborate on 1-1 relationships a little bit.   In your example,
with one person having one tax id, that would be a field in the table.
There would be no reason to break that out to a different table.

A good example of a 1-1 need would be in the construction field.  Say
you are writing an application to manage a companies construction
contracts.  This company does both residential and commercial.  One
contract can be either commercial or residential, but not both.  Both
contracts have alot of the same information, but commercial contracts
require 50 additional fields that residential does not.  Likewise,
residential contracts require 50 fields that commercial does not.
Assume they share 50 fields in common.

Now, you could have a Contracts table with 150 fields, or you could
have a Contracts Table with 50 fields (the common ones), a Commercial
with 50 fields (linked on ContractNumber), and a residential with 50
fields.  The benefit to having 3 tables is that on any given contract,
50 fields are going unused, but still require storage space.  By
breaking out the contract data, then you are actually using less space
by using 3 tables, especially as the number of records grows.

As far as Autonumbers go, I don't think it matters in practice one way
or another.  If you have a existing unique identier (SSN, Contract
Number, Employee ID, etc.) then you could use that.  You could also
create a AutoNumber, and save both.  The main thing is not to use a
AutoNumber for an audit purpose, as you WILL have gaps in the sequence
number.  An AutoNumber should be to guarntee uniqueness, and NOTHING
else.  Too many people get wrapped into wanting to reset AutoNumbers,
start with a certain number, etc.

I do tend to avoid them for the simple reason of autonumbers make
merging data from two databases a pain.  If there is an available
unique key, I try and use it.  Well, I do tend to avoid SSN's, but that
is due to having mine stolen.

Chris Nebinger