Re: Surrogate primary key plus unique constraint vs. natural primary key: data integrity?
Date: Sun, 1 Sep 2013 01:59:19 -0700 (PDT)
Message-ID: <09b666fe-19b5-4f4b-a730-306192143eea_at_googlegroups.com>
Am Samstag, 31. August 2013 19:56:48 UTC+2 schrieb James K. Lowden:
> On Sat, 31 Aug 2013 07:10:09 -0700 (PDT)
>
> karl.scheurer_at_o2online.de wrote:
>
>
> Let's say instead you use CUSTID for the key, and just keep the name by
>
> reference. If you don't keep the history, you have no way to query by
>
> historical name, and no way to distinguish between orders received
>
> under new and old names. If you do keep the history, you have at best
>
> a fragile way: you can *infer* that orders received prior to the change
>
> used the old name, but that inference relies on that date being
>
> correct, something the DBMS cannot ensure. Changing that date changes
>
> history, intentionally or not.
>
>
You are right! Based on our application, querying for history client name
was newer a item. A correct identification for aggregating queries is all
what was required. Adding historical question is easy with
client_orders {client_id, order_no, client, location}
m.f.G.
Karl Scheurer
Received on Sun Sep 01 2013 - 10:59:19 CEST