Esiste una fonte canonica che supporta "tutti i surrogati"?

"Tutti i PK sono surrogati" non è affatto una strategia molto solida e certamente non quella che è probabile che tu possa trovare una fonte "autorevole" per .

In primo luogo, pensa a cosa si intende per "chiave primaria" in questo contesto. Nel modello relazionale non ci sono chiavi "primarie", ovvero nessuna chiave fondamentalmente diversa da qualsiasi altra chiave della stessa tabella. In linea di principio tutte le chiavi in un database relazionale possono e godono dello stesso stato e hanno le stesse caratteristiche e funzioni, tranne nella misura in cui il progettista del database sceglie diversamente. L'individuazione di una qualsiasi chiave in una tabella con più chiavi è quindi essenzialmente arbitraria (era la parola usata da E.F.Codd), soggettiva e puramente psicologica (la visione di Chris Date, collega e collaboratore di Codd). A meno che non venga spiegata la distinzione che viene tracciata tra una chiave "primaria" e qualsiasi altra chiave, è quindi abbastanza priva di significato e di nessun merito per affermare che una tale chiave "dovrebbe" o "deve" essere qualsiasi cosa.

In secondo luogo, l'argomento ha molto poco a che fare con gli indici, che sono una caratteristica di archiviazione fisica. Le chiavi sono una questione logica, non fisica e non vi è alcuna ragione assoluta per supporre che le considerazioni di archiviazione di una chiave "primaria" siano o debbano essere diverse dalle altre (vedere paragrafo precedente). Potremmo ragionevolmente presumere che qualunque sia la struttura di archiviazione utilizzata, il sovraccarico di memoria sarà in qualche misura maggiore con una chiave surrogata rispetto a tale chiave, ma come sempre la migliore risposta è "dipende". Le decisioni di archiviazione devono essere prese caso per caso e le regole generali sono di pochissimo aiuto.

In terzo luogo, da un punto di vista logico il requisito assoluto di una chiave surrogata ha molto poco senso. Il requisito per una chiave naturale è esattamente lo stesso con o senza un surrogato. La necessità che le informazioni siano identificabili nel dominio del discorso (cioè con una chiave naturale AKA "business key", "domain key") è la stessa. Sì, potrebbe essere necessario aggiornare le chiavi, ma a volte questa è la natura delle cose. L'aggiunta di un surrogato di per sé non rende necessariamente più facili gli aggiornamenti delle chiavi e talvolta può renderli più difficili.

Le chiavi primarie e quelle esterne non devono essere leggibili. Il loro scopo è di mantenere la struttura relazionale interna del database, non quella di essere letto da un essere umano.

Naturalmente, se c'è una chiave naturale appropriata che cambierà mai (ritengo che siano rari come i denti di gallina oi quadrifogli, ma ...), puoi usare quello, e alcuni clienti lo renderanno uno dei loro requisiti.

Ma perché aggiungere la complessità aggiuntiva a un sistema di database, con un piccolo vantaggio apprezzabile? Le chiavi Surrogate primarie sono generate dal sistema, garantite come uniche, garantite per non cambiare mai e sono lo stesso tipo di dati per tutte le tabelle. Avranno lo stesso comportamento affidabile in tutte le circostanze.

Se stai cercando una risorsa canonica che supporti questa pratica, non ne troverai una. Ci sono altrettanti designer dall'altra parte del corridoio che difenderanno brutalmente il loro uso di chiavi naturali composte con indici cluster come chiavi primarie e tutte le risorse canoniche indicano che è la scelta del progettista.

Vedi anche
link