Una chiave primaria dovrebbe essere immutabile?

Hai solo bisogno della chiave primaria di essere immutabile se è collegata a una chiave esterna o se è usata come identificatore al di fuori del database (per esempio in un URL che punta a una pagina per l'elemento ).

D'altra parte, solo è necessario avere una chiave mutabile se contiene alcune informazioni che potrebbero cambiare. Uso sempre una chiave surrogata se il record non ha un identificatore semplice e immutabile che può essere utilizzato come chiave.

Una chiave primaria dovrebbe essere composta da qualunque tupla sia necessaria per determinare l'unicità. Se i dati possono essere modificati o meno è irrilevante. Importa solo l'unicità del disco. Questa è la progettazione concettuale del database.

Quando entriamo nel regno dell'implementazione, la cosa più sicura da fare è semplicemente usare una chiave surrogata.

Sì, a mio parere una chiave primaria dovrebbe essere immutabile.

Anche se ci sono ovvie chiavi candidate, io uso sempre una chiave surrogata. Nelle poche occasioni in cui non l'ho fatto, me ne sono quasi pentito. E a prescindere da quanto sia immutabile la chiave, non puoi salvaguardare gli errori di immissione dei dati, dicendo agli utenti che non possono modificare quel bit di informazioni perché è una chiave primaria che non si lava tristemente.

I meccanismi di memorizzazione nella cache tra database e utente perderanno l'efficacia se cambiano le chiavi primarie.

Perché no? Perché vuoi eliminare una colonna?

Solo perché i requisiti richiedono che tre colonne siano univoci, non significa che debba essere la chiave primaria. Potresti pensare che la regola durerà per sempre (ricordati durante quell'incontro quando il caporeparto della testata ha giurato che non cambierebbe mai? Sai, quello che è appena stato licenziato.), Ma non lo farà.

Non vengo pagato per ogni aggiornamento a cascata che implemento e un bonus se lo codifico personalmente.

Il computer non richiede alcun significato per una chiave; IMHO, le chiavi sono per i computer, lascia che le persone rovinino il resto dei dati.

Non è una cattiva pratica avere una chiave i cui valori possono cambiare.

Le proprietà di una buona chiave includono la stabilità. L'immutabilità è ideale ma non un prerequisito. Introdurre una chiave artificiale a fini di immutabilità è una cattiva pratica.

Prendi l'esempio del numero di libro standard internazionale (ISBN) . È molto stabile ma non immutabile: a volte gli editori di libri commettono errori e - orrore! - possono verificarsi numeri ISBN duplicati. Significa che l'ISBN non dovrebbe essere accettato come chiave candidata in un database informatizzato? Ovviamente no. Uno dei vantaggi di ISBN è che ha una fonte attendibile che risolverà i problemi per tutti gli utenti a livello globale.

Esistono altre varianti di un buon codice ISBN che non mancherà di una chiave intera senza significato a incremento automatico, ad es. la familiarità (tutti gli utenti del libro conoscono o hanno familiarità con il codice ISBN), verificabile (il codice ISBN è stampato su tutti i libri moderni), può essere convalidato con riferimento al DBMS (il codice ISBN è a larghezza fissa e include un checksum), ecc.

Tutto ciò che può essere immutabile dovrebbe essere. Aiuta a garantire la correttezza e aiuta quando vuoi rendere l'applicazione multithread.

Sì, una chiave primaria deve essere immutabile, oltre ad essere non nulla e univoca. Tuttavia, devo ancora trovare un database che impone l'immutabilità delle chiavi primarie, quindi è probabile che tu possa andare avanti e modificare i loro valori se lo desideri.

Come alcuni commenti hanno già detto, una soluzione è usare una nuova chiave primaria

Ad esempio (seguendo l'esempio di @onedaywhen), supponiamo che esista la tabella Libri che memorizza un elenco di libri e che abbiamo "utilizzato" per determinare il codice ISBN come chiave primaria. Tuttavia, alcuni autori hanno commesso l'errore di digitare un codice ISBN errato, quindi hanno chiesto di modificare il codice ISBN, coinvolgendo le seguenti attività:

• crea un nuovo registro nella tabella Libri
• punta tutti i riferimenti dal vecchio codice ISBN al nuovo codice ISBN. (*)
• Infine, elimina il vecchio registro dalla tabella Libri.

(*) questo potrebbe essere banale per trovare tutti i riferimenti per un modello di database che usa chiavi esterne ma alcuni modelli ne mancano.

Table Books
ISBN  is the primary key
NAME is a simple field.
etc.

Lo cambiamo come

Table Books
InternalBookId as the primary key
ISBN as a simple field or an indexed field.
NAME is a simple field.
etc.

Dove il nuovo InternalBookId potrebbe anche essere un valore autonumerico.

Gli aspetti negativi:

• aggiunge un nuovo campo che utilizza più spazio / risorse.

• potrebbe richiedere la riscrittura dell'intero modello.

• il nuovo modello potrebbe essere meno spiegato da solo.

Il professionista

• Permette di mutare la "chiave primaria".
• Permette anche di eliminare o refactoring della "chiave primaria", ad esempio, per cambiare libri in ISBN-13 è così semplice da eliminare la colonna precedente e crearne una nuova

Nuova tabella:

Table Books
InternalBookId as the primary key
ISBN13 is a new field.
NAME is a simple field.
etc.