Re: Surrogate primary key plus unique constraint vs. natural primary key: data integrity?

From: <karl.scheurer_at_o2online.de>
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

Original text of this message