My 2 cents (Canadian): Putting everything in one table is not a horrible idea: Claimant ID (PK), Claimant Type, Common columns, Type 1-specific columns, Type 2-specific columns, etc.
An alternative is: 1) Claimant table with Claimant ID (PK), Claimant Type, Common columns 2) Claimant Type 1 table with Claimant ID (PK and FK on Claimant Table) and Type 1-specific columns 3) Claimant Type 2 table with Claimant ID (PK and FK on Claimant Table) and Type 2-specific columns Etc. Regards, Stephen Markson The Pharmacy Examining Board of Canada 416.979.2431 x251 > Hmm. > > Not seeing it. What I'm trying to do is squeeze IDs for wholly > dissimilar entities into one table, and use that as a 'dispatcher' to > find them all later. > > FWIW, here's my thinking: > > The court clerk is assigning unique Claimant ID numbers to a crowd of > Individuals, Corporations (fictional people) and Proxies > (representatives), lined up with their forms filled out. Individuals > and Proxies show their SSN and people info. Corporations flash their > FEIN and business info (two different forms, ID number domains, data > structures). The clerk registers each SSN and FEIN to a Claimant ID > number, and kumbaya, everyone is now a member of the same claimant > pool. Then they go out and tear each other to shreds. > > So the assistant clerk fills in the table: > > CLAIMANT > - PK - ClaimantID > - FK - IndividualID (SSN) ... (links to personal info) > - FK - CorporationID (FEIN) ... (links to business info) > > ... and to ensure that my tribe gets theirs, I code stuff like this: > > SELECT + > BigBucks INTO vPayout INDICATOR vInd + FROM + > Estate t1, + > LawSuit t2, + > ClaimStatus t3, + > Claimant t4, + > &vEntityTable t5 + > WHERE + > t1.EstateID=t2.EstateID AND + > t2.LawSuitID=t3.LawSuitID AND + > t3.ClaimantID=t4.ClaimantID AND + > t4.&vEntityID=t5.&vEntityID AND + > t5.&vEntityName='MyTribe' > > ... where vEntityTable, vEntityID and vEntityName switch to the > intended sub-table. > > Does that make sense? > > And thanks Albert, very much. >
