Esiste una fonte canonica che supporta i “tutti surrogati”?

Question

Sfondo

IL "tutti i PK devono essere surrogati" l'approccio non è presente in Il modello relazionale di Codd o qualsiasi Norma SQL (ANSI, ISO o altro).

Anche i libri canonici sembrano eludere queste restrizioni.

Lo schema del dizionario dati di Oracle utilizza chiavi naturali in alcune tabelle e chiavi surrogate in altre tabelle.Ne parlo perché queste persone devono sapere una o due cose sulla progettazione RDBMS.

PPDM (Professional Petroleum Data Management Association) raccomandano gli stessi libri canonici:

Utilizzare le chiavi surrogate come chiavi primarie quando:

1. Non esistono chiavi naturali o aziendali
2. Le chiavi naturali o aziendali non sono valide (cambiare spesso)
3. Il valore della chiave naturale o aziendale non è noto al momento dell'inserimento del record
4. Le chiavi naturali a più colonne (di solito diversi FK) superano le tre colonne, il che rende i join troppo dettagliati.

Inoltre non ho trovato una fonte canonica che affermi che le chiavi naturali devono essere immutabili. Tutto quello che trovo è che devono essere molto stabili, cioè devono essere cambiati solo in occasioni molto rare, se non mai.

Cito PPDM perché anche queste persone devono sapere una o due cose sulla progettazione RDBMS.

Le origini dell'approccio "tutti surrogati" sembrano provenire dalle raccomandazioni di alcuni framework ORM.

È vero che l'approccio lo consente modellazione rapida di database non dovendo fare molte analisi aziendali, ma a scapito della manutenibilità e leggibilità del codice SQL.Viene fatta molta previsione per qualcosa che potrebbe o meno accadere in futuro (il PK naturale è cambiato, quindi dovremo utilizzare la funzionalità di aggiornamento a cascata dell'RDBMS) a scapito delle attività quotidiane come dover unire più tavoli in ogni query e dover scrivere codice per importare dati tra database, una procedura altrimenti molto semplice (a causa della necessità di evitare collisioni PK e dover creare in anticipo tabelle di fasi/equivalenze).

Un altro argomento è che gli indici basati su numeri interi sono più veloci, ma ciò deve essere supportato da benchmark.Ovviamente, varchar lunghi e variabili non sono buoni per PK.Ma gli indici basati su varchar breve e di lunghezza fissa sono veloci quasi quanto gli interi.

Le domande

- Esiste qualche fonte canonica che supporta l'approccio "tutti i PK devono essere surrogati"?

- Il modello relazionale di Codd è stato sostituito da un modello relazionale più nuovo?

Answer 1

"Tutti i PK sono surrogati" non è affatto una strategia molto valida e certamente non uno per il quale difficilmente troverai una fonte "autorevole"..

Innanzitutto pensa a cosa si intende per "chiave primaria" in questo contesto.Nel modello relazionale non esistono chiavi "primarie", ovvero nessuna chiave che sia fondamentalmente diversa da qualsiasi altra chiave della stessa tabella.In linea di principio tutte le chiavi in ​​un database relazionale possono godere e godono dello stesso status e hanno le stesse caratteristiche e funzioni, tranne nella misura in cui il progettista del database sceglie altrimenti.L'individuazione di una chiave qualsiasi in una tabella a chiavi multiple è quindi essenzialmente arbitraria (questa era la parola usata da E.F.Codd), soggettiva e puramente psicologica (l'opinione di Chris Date, collega e collaboratore di Codd).A meno che non venga spiegato quale distinzione viene tracciata tra una chiave "primaria" e qualsiasi altra chiave, è quindi piuttosto privo di significato e di nessun merito affermare che tale chiave "dovrebbe" o "deve" essere qualcosa.

In secondo luogo, l’argomento ha ben poco a che fare con gli indici, che sono una funzionalità di archiviazione fisica.Le chiavi sono una questione logica, non fisica e non vi è alcun motivo assoluto per presumere che le considerazioni sull'archiviazione di una chiave "primaria" siano o debbano essere diverse da quelle delle altre chiavi (vedere il paragrafo precedente).Potremmo ragionevolmente presumere che qualunque sia la struttura di stoccaggio utilizzata, il sovraccarico di stoccaggio sarà in una certa misura maggiore con una chiave surrogata che senza tale chiave, ma come sempre la risposta migliore qui è "dipende".Le decisioni relative allo stoccaggio dovrebbero essere prese caso per caso e le regole generali sono di scarso aiuto.

In terzo luogo, da a logico Da questo punto di vista, il requisito assoluto di una chiave surrogata ha ben 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 "chiave aziendale", "chiave di dominio") è la stessa cosa.Sì, potrebbe essere necessario aggiornare le chiavi, ma a volte questa è la natura delle cose.L'aggiunta di un surrogato non rende necessariamente di per sé gli aggiornamenti chiave più facili da gestire e talvolta può renderli più difficili.

Answer 2

Tasti primari ed estranei non devono essere leggibili. Il loro scopo è quello di mantenere la struttura relazionale interna del database, non essere letta da un essere umano.

Naturalmente, se c'è una chiave naturale appropriata che mai cambierà (rivendicazione che questi sono rari come denti rari o trifole a quattro foglie, ma ...), puoi usarlo, E alcuni clienti rendono quella delle loro esigenze.

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

Se stai cercando una risorsa canonica che supporta questa pratica, non ne troverai uno. Ci sono altrettanti designer dall'altra parte del corridoio che difenderanno vizialmente il loro uso di tasti naturali e compositi con indici in cluster come chiavi primarie e tutte le risorse canoniche dicono che è la scelta del designer.

Vedi anche
http://en.wikipedia.org/wiki/surrogate_key