On Wed, May 22, 2019 at 11:07 AM Rich Shepard <rshepard@xxxxxxxxxxxxxxx> wrote:
On Wed, 22 May 2019, Francisco Olarte wrote:
> You are not reading what we write to you. Note YOU AND ONLY YOU are the
> one speaking of PK. We are speaking of "unique identifier" ( that would
> be, IIRC, "candidate keys", you can peek any as your PK, or even introduce
> a new synthetic one with a sequence, or a femto second exact timestamp or
> whatever ).
Francisco,
Let me clarify.
The organizations table has org_id (an integer) as PK.
The people table has person_id (an interger) as PK and org_id as the
reference to organization.org_id.
Does this help?
Francisco hit just the point I was making. I never said org_name should be the primary key. We all acknowledge org_id will the the primary key. But the whole question that would solve your issue is what other field or fields identify an organization in your data file.
You need two unique identifiers:
- A "natural" one from your data file that identifies unique information about an organization. This is NOT the primary key on organizations table
- A "synthetic" one - org_id, generated in the organizations table.
The whole point of the (1) natural unique identifier is this is how you can *easily* link org_id back to the person record in your data file.
You say we don't need to see your data file to answer the question. To me, it's still clear that if you were to share a sample of your data file (obviously, with fake data), all of this back and forth would quickly end. This is all way too abstract.
Thanks,
Jeremy
