Una chiave surrogata dovrebbe mai essere esposta a un utente?

Spesso in una tabella che non ha una chiave naturale, è comunque utile che gli utenti possano avere un identificatore generato in modo univoco. Se la tabella ha una chiave primaria surrogata (e in tal caso te lo aspetteresti sicuramente) tale chiave dovrebbe essere esposta all'utente o dovrebbe essere usato un altro campo a tale scopo?

Un motivo per non esporre la chiave surrogata è che ora non è possibile eseguire operazioni che preservano la relazione tra i record, ma modificare i valori chiave, come alcuni tipi di cancellazione / reinserimento, molti metodi di copia dei dati da un database a un altro, ecc.

Il vantaggio principale di esporre la chiave surrogata è la semplicità di utilizzare un campo che hai comunque.

In quali circostanze è meglio esporre direttamente la chiave surrogata agli utenti?

Devi essere pronto per qualsiasi identificatore esposto agli utenti / clienti che necessitano di essere modificati, e cambiare l'identità di una riga in un database e propagare tale modifica a tutte le chiavi esterne richiede solo di interrompere i dati.

Se i dati non hanno una chiave aziendale naturale, è possibile aggiungere un campo aggiuntivo per un "identificatore aziendale". Questo dovrebbe essere ottimizzato per i processi per cui è utilizzato. La voce della tastiera del telefono significa solo un numero. Al telefono / verbale significa evitare simboli di suono simili (B / D, M / N, ecc.). Puoi anche generare automaticamente qualche frase facilmente memorabile ("gelatina verde").

L'effetto di ciò è che l'azienda può in seguito cambiare il modo in cui desidera fare riferimento ai record e l'unica modifica dello schema di dati è l'aggiunta di una nuova colonna per quello stile di ID o la trasformazione degli ID già presenti. La modifica non si propaga attraverso l'intero database e hai ancora un ID (il surrogato) che è valido nel tempo.

In breve, eviterei di esporre agli utenti le chiavi surrogate. Come sottolineano i commenti, le chiavi surrogate non dovrebbero quasi mai cambiare. Al contrario, le aziende vogliono cambiare tutto. Se la chiave surrogata è esposta, è solo una questione di tempo prima che l'azienda voglia cambiarla.

Come nota a margine, quando dico "esporre" qui, intendo dare la chiave all'utente con l'aspettativa che la utilizzino direttamente (come chiamare per supportare con il loro numero d'ordine).

In alcuni casi, sono previste chiavi surrogate e hanno senso per gli utenti. Il mio esempio preferito è "numero d'ordine". Il numero dell'ordine non è in realtà una chiave naturale: una chiave naturale potrebbe essere il timestamp più l'utente, o forse di più se si prevede che gli utenti generino più di un ordine all'interno della granularità del timestamp.

Tuttavia, gli utenti comprendono e si aspettano la comodità di un numero d'ordine. Non vi è alcun danno e molto valore se si informano gli utenti su di loro.

D'altra parte, alcuni tasti surrogati non hanno senso per un utente. Certo, la mia compagnia di assicurazione sanitaria ha una chiave surrogata che mi identifica in base all'ID del mio membro, alla data di nascita, al corriere, ecc., Ma non mi interessa, mi preoccupo delle informazioni sulla mia carta (che spesso include ID sul mio datore di lavoro e non sono unici in tutto l'universo ... Da qui la chiave surrogata della compagnia assicurativa).

È necessario esporre una chiave surrogata solo se è un GUID / UUID generato correttamente *. L'esposizione di chiavi surrogate sequenziali è il numero 4 dei 10 principali problemi di sicurezza di OWASP.

* In pratica, è meglio supporre che non sia stato generato correttamente per questi scopi, a meno che non si sappia che è stato creato da un generatore di numeri casuali o pseudo-casuali sicuro crittograficamente.

Se una tabella non ha una chiave naturale, le chiavi surrogate consentono righe come questa.

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

Chiamerei queste chiavi artificiali invece delle chiavi surrogate, ma questa distinzione non è importante per questa domanda.

Ora, supponendo che ci siano dati importanti che fanno riferimento a queste chiavi surrogate tramite chiavi esterne, come fanno gli utenti finali a sapere quale riga aggiornare se non conoscono i valori delle chiavi surrogate?

Nelle parole di laici:

• I surrogati dovrebbero essere nascosti all'utente.
• È necessario esporre all'utente un'altra chiave del candidato commerciale.
• Se non esiste un'altra chiave candidata, è necessario mostrare il PK. Ma in questo caso il PK non è considerato un surrogato poiché non sostituisce un'altra colonna.

dovresti esporre SOLO un campo a un utente che fornisca all'utente informazioni utili, direttamente o nel segnalare i difetti.

viceversa, si dovrebbe SEMPRE esporre "chiavi primarie surrogate" quando sono i mezzi principali per identificare un record (semplice o complesso) per un'interazione eseguita dall'utente.

Non dovrebbe importare se si espongono le chiavi o meno all'utente finale. L'applicazione deve eseguire l'autorizzazione necessaria in modo tale che la semplice conoscenza di un ID ordine, ad esempio, non possa consentire loro di accedere a qualcosa a cui normalmente non avrebbero accesso.

avvertenza: presuppone un'applicazione basata su Web o di livello n in cui l'autorizzazione lato server è possibile / fattibile. Se hai un'app VB che esegue direttamente sql, questo è un altro problema.