Sto cercando di progettare lo schema DB del mio nuovo progetto e ho bisogno di alcuni suggerimenti. Sto pensando di avere una colonna in più per alcune tabelle che è un UUID. Volevo principalmente per le tabelle che contengono dati accessibili tramite REST, quindi non voglio esporre la chiave primaria. La mia preoccupazione è che quando voglio aggiornare una tabella, ho bisogno di eseguire un'altra query solo per prendere la chiave primaria originale.
Che ne pensi?
Avere più chiavi, andare avanti e farlo. La tua applicazione può avere una chiave primaria diversa dal tuo database; So che all'inizio potrebbe sembrare strano, ma ottieni il meglio da entrambi i mondi andando su questa strada.
Gli UUID hanno molti vantaggi, ma producono indici cluster generalmente orribili. Pertanto, puoi utilizzare un int come indice PK / cluster nel tuo DB, ma anche un altro indice univoco sulla colonna id esterna. Ciò potrebbe richiedere un join aggiuntivo per molte query, ma va bene, perché nei DB relazionali, le inner join su colonne int auto incrementate sono molto veloci.
Un altro vantaggio di questo approccio a doppia chiave è la possibilità di distribuire facilmente il tuo DB in modo geografico. Dal momento che gli UUID sono globalmente unici, due DB geograficamente separati non dovranno rallentare il coordinamento delle loro chiavi, a patto che ci si assicuri che il DB int di DB non abbandoni mai il DB e non sia utilizzato dal servizio di riposo.
Ecco un altro punto, il tuo ID esterno non deve nemmeno essere un UUID, ci possono essere anche altre opzioni.
Non abbiate paura di avere più chiavi, nascondendo la vostra chiave DB dal resto. Api consumatori è una buona cosa.
La maggior parte delle chiavi che ho mai usato è stata due, ma nella situazione giusta, posso immaginare fino a quattro giustificazioni (chiave DB, chiave dell'applicazione, chiave aziendale, chiave cliente)
Non ha senso avere due chiavi primarie.
No, non lo sono. Smetti di preoccuparti di numeri arcani come pagine e frammentazione e fai qualche test.
In ogni caso, se hai entrambi e indicizzi l'UUID, hai lo stesso problema
In ogni caso se hai entrambi è decisamente più grande
Gli in-sequenziali hanno alcuni problemi principali risolti con gli UUID, uno dei quali indovina il prossimo id o quanti ordini hai preso.
Queste sono vere preoccupazioni di sicurezza e commerciali e dovrebbero, di per sé, essere sufficienti a giustificare il fatto che non si utilizzano affatto le interezze auto.
Non cercare di risolvere i problemi con le soluzioni hacky, basta sostituirli con lo standard del settore.
Se il tuo unico obiettivo è nascondere la chiave primaria dall'interfaccia REST, allora consiglierei contro di essa. Invece, crittografare le tue chiavi sarebbe una buona soluzione per questo.
Il problema con l'utilizzo delle chiavi primarie come identificatore pubblico per la tua entità è che stai perdendo i dettagli della soluzione di archiviazione dei dati per i tuoi clienti (e di conseguenza, per tutta la tua applicazione). Questo può avere implicazioni sulla sicurezza, nel senso che le modifiche al back-end delle applicazioni possono essere più complicate. Gli UUID aiutano a risolvere questo problema fornendo un identificatore alternativo completamente indipendente dalla tecnologia del database.
Gli UUID sono solo una soluzione a questo problema, con il vantaggio intrinseco che, per tutti gli scopi pratici, sono garantiti come unici. Tuttavia, se ti sei sforzato di utilizzare qualcosa di diverso dalla chiave primaria come identificatore, potresti scoprire che l'utilizzo di una stringa arbitraria o solo un altro identificatore numerico fornisce URL più graditi.
Un'altra considerazione è che se stai usando GUID / UUID come identificatore pubblico per la tua entità, probabilmente avrai bisogno di una sorta di indice per loro. Dato che occupano molto più spazio degli interi, il tuo indice sarà molto più grande.
Questo è un problema comune che ho incontrato me stesso molte volte. Ho finito per scendere la rotta "usa solo un numero per l'id", il che significa che non è così brutto per i client vedere quegli UUID.
L'unico altro modo, come hai già eluso, è quello di nascondere quell'ID dietro qualche tipo di query, alla quale dovrai fornire i parametri per recuperare l'UUID corretto, tuttavia, ciò significa che puoi anche stai usando quei parametri come chiave primaria per la tabella!
Direi che non c'è modo di fare REST (cioè il trasferimento di stato di un modello) senza essere in grado di identificare l'istanza di cui si sta eseguendo il REST, quindi avrai bisogno di una chiave, qualunque sia la forma che assume la chiave.
Se la tua preoccupazione è dovuta alla sicurezza, vedo il problema così com'è nel codice di convalida dei messaggi del tuo server, non che il client veda Id. Se un hacker vuole caricare alcuni dati dalla tua tabella, non avranno bisogno di id per farlo. E anche tu dovresti convalidare le richieste, quindi nessuna roba oscura arriva comunque ai tuoi livelli aziendali, ad esempio l'autenticazione e l'autorizzazione dei messaggi.
Per tornare alla tua domanda:
"accessible through REST, so I don't want to expose the primary key"
Penso che sia l'opposto, è necessario esporre la chiave primaria per fare REST.
EDIT: come sottolineato da @Murph, in realtà offre agli hacker una migliore possibilità se dai Id al cliente - non lo sapevo. Potrebbe essere che altre risposte qui (sto guardando il più breve che dice di crittografare la chiave) potrebbero essere più corrette per la tua situazione. Modifica 2: Sembra che gli UUID non siano più sicuri degli Ints ...
Leggi altre domande sui tag database database-design relational-database schema