Just a point about terminology here: there is no such thing as more then one primary key. An entity has a primary key that uniquely identifies it; it can't have two unique identifiers. The primary key itself may be composite, in which case the key is composed of more than one attribute. If this is how you have defined your table then a composite key is the way to go.
However, looking at your data I think there is an example of a surrogate key in there. Account numbers are a classic example of surrogate keys (a value created that has no business meaning, so whose sole purpose is to uniquely identify a thing). I don't know the details of yourr data, but couldn't the account number be used as the primary key? I mention it because composite keys are always best avoided if possible.
Yes...i'm sorry i meant to say two attributes that make up the primary key.
That example above was pretty bad that i thought of on the spot...yes in that example i guess accountNumber could and probably should be the primary key. However i often work on database tables (that already exist and difficult to change) that have multiple columns as the primary key...so i know now that composite mapping is whats required.
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop