Includere i dati del record nel numero ID

I miei due centesimi:

Nota: non confondere la concatenazione di più valori in una singola stringa e utilizzarla come PK con PK multi-colonna.

Detto questo:

Concatenare più dati non chiave in una stringa per popolare una colonna chiave ha diversi svantaggi:

• Le persone potrebbero indovinare gli ID per scopi di pirateria
• Quando i dati non chiave cambiano, la chiave viene lasciata obsoleta e deve essere modificata per riflettere le modifiche apportate ai dati
• Tutte le colonne da concatenare nella stringa chiave devono essere conosciute al momento dell'inserimento.

Tuttavia, ho visto identificatori che sono il risultato della concatenazione di molti altri valori nei numeri di conto bancario nel mio paese in cui la stringa è composta dal codice bancario, dal codice filiale bancario, dal tipo di conto, da una sequenza, quindi da un errore numero cheking Non so perché questa pratica sia ancora in uso. Ho anche visto questo tipo di pratica nell'identificatore dell'account del libro mastro che utilizza un ID gerarchico come 10.1.2.3.0.1.

La mia raccomandazione è:

• Non farlo.
• Se esiste una buona chiave naturale, usala (deve essere stabile, cioè molto raramente cambia - al contrario di mai -, deve essere conosciuta al momento dell'inserto). Dato che stiamo parlando di una tabella di persone, ci saranno molte circostanze in cui una buona chiave naturale non esisterà.
• Se la chiave naturale è composta da più di tre colonne, utilizzare invece una chiave surrogata sequenziale, anche se è necessario creare una chiave univoca sulla chiave naturale candidata composta per applicare le regole aziendali.
• Se non esiste una chiave naturale valida, utilizza un surrogato.

Dipende dalle regole aziendali. Se si tratta di un sistema di gestione stipendi un numero di dipendente (che è una chiave surrogata) è una buona opzione .

Un buon punto su cui riflettere è che una chiave sequenziale artificiale generata da una certa autorità riconosciuta può essere considerata una chiave naturale da altre organizzazioni. Le chiavi sono artificiali solo quando le generate all'interno della tua organizzazione in modo sequenziale o casuale e non hanno alcun significato.

There was a discussion about whether it was desirable to have information about each person encoded in their ID number.

La codifica di più elementi di dati in un singolo campo è Progettazione errata se non altro per il fatto che interrompe le regole di base per la normalizzazione dei dati.

Alternatively, it could contain no semantic content at all.

Questa sarebbe la mia scelta.

On one hand it could be nice for sanity checking that we can make sure the ID number matches the data in each field ...

Se è necessario assicurarsi che sia stato inserito il numero ID "giusto", prendere in considerazione l'aggiunta di una cifra di controllo. OK, non è strettamente [solo] un numero, ma questo non dovrebbe fare alcuna differenza. L'uso di una cifra di controllo protegge da errori semplici come la trasposizione di cifre e il malfunzionamento.

Questa è una delle ragioni per cui evito numeri puri e sequenziali (sequenze, campi numerici autonome, ecc.) come identificatori di dati. Come chiavi interne, "surrogate", gestite dall'applicazione e che non vedono mai la luce del giorno, forse, ma mai in alcun senso che qualcuno potrebbe dover digitare una copia in.

Se hai bisogno di verificare che hai a che fare con la persona giusta Person , allora un ID da solo non è sufficiente.

On the other hand, if something in the record needed to change, we might have to figure out whether to change the person's ID, which could cause problems.

La maggior parte sicuramente causa problemi; cambiare le Primary Key non è qualcosa che dovresti prendere alla leggera, specialmente quando c'è [anche] una [piccola] modifica che potresti ottenere [tutti] quegli ID sbagliati.

Includere le informazioni nell'ID del record:

I lati positivi:

1. Minima (ma discutibile) comodità iniziale per i pochi umani che hanno bisogno di leggere l'archivio dati sottostante.

I lati negativi:

1. Quasi impossibile apportare modifiche. Cosa succede quando l'Id deve improvvisamente includere le informazioni X? Cosa succede quando l'informazione X deve essere rimossa o diventa irrilevante?

2. Inconvenienti per i pochi umani che devono utilizzare l'archivio dati sottostante. Non c'è nulla di più semplice di un ID intero per identificare un record in un database. Ed è facile da usare.

Quando è preferito? Raramente. In alcune tabelle di ricerca ridotte, è preferibile. In ogni altro caso, non è preferito.

Principalmente, la chiave primaria ha uno scopo, per identificare univocamente un record. Non dovrebbe avere più di uno scopo. Identifica in modo univoco un record in modo che altri record nel database possano farvi riferimento in modo efficiente. Perché la tabella X deve conoscere il numero di sicurezza sociale di un record nella tabella Persona? Risposta: non è così. Ha solo bisogno di conoscere l'identità della specifica registrazione della persona a cui si riferisce. Quindi quell'identità dovrebbe essere chiaramente adatta a quel compito.

Esempio, una volta ho lavorato con un database che aveva solo chiavi naturali. Quindi tutto tranne una manciata di tabelle radice aveva più chiavi primarie. Pertanto, per eseguire una semplice query su ordini di vendita, dovevo collegare il ramo aziendale, il numero dell'ordine e la riga dell'ordine solo per ottenere le informazioni sull'ordine. Ora immagina cosa dovevo fare per collegare le linee di fatturazione agli ordini o qualcosa di più complicato? Dovrebbe essere stato un singolo collegamento su un campo ID ogni volta. È stato facile leggere la prima volta, certo. Ma usare il database è stato un grande inconveniente.

Pensa anche alla sicurezza. Se si identificano questi record OVUNQUE in base a dati che potrebbero essere sensibili, alla fine ci saranno dati sensibili da qualche parte che non dovrebbero? "Non dovrebbe" essere definito dai requisiti, dalle esigenze del cliente e dal Data Protection Act.

Potrebbe essere 'criptato', ma presumo che se lo vuoi per l'efficienza del controllo incrociato - non sarà pesantemente crittografato, sarà solo un po 'offuscato quando lo costruisci per concatenazione o altro. Non è abbastanza buono per chiamare "sicuro".