Mi chiedo, è brutta o buona idea utilizzare la chiave primaria di incremento automatico come identificatore di entità aziendale come Partner Id o Account Number?È una cattiva idea utilizzare la chiave primaria di un database come identificatore dell'oggetto business?
Inoltre, quali sono le insidie che posso affrontare se scelgo questo approccio?
Non credo che tutti condividano la stessa opinione, ma penso che sia una cattiva pratica. Passare gli ID all'utente come "chiave" non è corretto a mio parere, per diversi motivi:
Nei nostri prodotti, utilizziamo sempre uno 'natural key', accanto alla chiave primaria, una chiave comprensibile per l'uomo.
Se non è disponibile alcuna chiave naturale comprensibile dall'uomo, ad esempio quando si tratta di una tabella di registrazione, è possibile ripristinare una chiave artificiale.
Credo che l'OP si stia chiedendo se è una buona idea usarlo come PK, basandosi sul commento successivo che hanno fatto. Inoltre, avendo lavorato con utenti di applicazioni in un ruolo di sviluppatore di supporto per un buon numero di anni, ho scoperto che gli utenti tendono effettivamente a collegarsi a un numero di tipo ID piuttosto rapidamente. Come in "Hey guarderai @ Record numero 14567 e dimmi se la descrizione è confusa?". Il mio avvertimento è che se un GUID viene usato come PK, se questo è il caso, allora l'uso di una chiave naturale è una grande idea (ma non avrei mai mostrato il PK effettivo all'utente in quel caso). – MER
@mer: Assolutamente non consiglio di sostituire il pk in favore di un nk. Questo è persino impossibile. –
Mi scuso per la mia mancanza di chiarezza. Non stavo suggerendo che tu gli dicessi di usare una chiave naturale come PK, (anche se è possibile http://www.agiledata.org/essays/keys.html (punto 2), è solo una cattiva idea) . Il mio unico punto avrebbe dovuto essere che, secondo la mia esperienza, agli utenti non piace l'idea di fare riferimento al numero, ma poi passare rapidamente all'utilizzo del numero generato come punto di riferimento primario per un dato record in un'applicazione (registrare il significato tutti i dati raccolti mostrati in un'applicazione come un numero di account, un file # o un progetto # ecc ...). – MER
Ci sono almeno tre caratteristiche desiderabili da tenere a mente quando si scelgono o progettano le chiavi: semplicità, stabilità e familiarità. Nella pratica, le persone spesso trovano più semplice ricordare e lavorare con parole e lettere anziché solo numeri ed è per questo che gli identificatori alfanumerici sono generalmente più comuni degli identificatori numerici (esempi di identificatori alfanumerici: targhe automobilistiche, numeri di volo delle compagnie aeree, prenotazione dei posti numeri, codici di stato e di paese, codici postali, indirizzi e-mail). Esistono studi e prove aneddotiche a supporto dell'idea che le chiavi alfanumeriche siano più utilizzabili dei numeri da soli. Inoltre, gli identificatori alfanumerici possono essere spesso più corti di quelli numerici. D'altra parte, gli identificatori sequenziali numerici sono molto comuni per alcune applicazioni (ad esempio numeri di fatture, numeri di conti bancari). Quindi suggerisco che tu debba essere guidato dalle esigenze dei tuoi utenti/aziende nel determinare queste cose.
Si noti che i generatori di sequenze a livello di motore DBMS spesso presentano limitazioni che li rendono inadatti per alcune applicazioni. Ad esempio potrebbe non essere facile aggiornarli o usarli in un'architettura di database distribuita. Un'altra limitazione comune è che solo una colonna "autoincrementante" può essere consentita per tabella, il che preclude il loro utilizzo come chiave aziendale se si desidera anche una chiave surrogata per la stessa tabella.
indica cosa non avevo spazio per commentare in precedenza, le chiavi primarie auto-incrementate possono rappresentare un problema nei progetti di applicazioni in cui i dati devono essere univoci su più database ... in questo caso ricorrere a un GUID come PK. Tuttavia, aggiungerò che la mia esperienza aneddotica con utenti reali che usano applicazioni reali è stata che credono che un nome sarà più facile quando inizialmente richiesto ma entro poche settimane dall'utilizzo dell'applicazione si riferiscono al valore della chiave surrogata molto più spesso del nome, (anche valori numerici completi). – MER
Non penso che tu abbia detto che usare ID o numeri è una cattiva idea su se stesso. Dipende. Spesso ID e numeri sono semplicemente perfetti. Chiediti: quale altra chiave stavi pensando altrimenti? E sarebbe meglio? Non penso che sia essenzialmente migliore. Un trucco con i numeri, non iniziare con 1, ma lasciare che un ID inizi con 1000000, l'altro con 20000000, ecc. – tvCa
@tvCa: Ovviamente non intendo Id o numeri. Intendo Id incrementale automatico come parte delle informazioni specifiche del database. – Vokinneberg
@Vokinneberg per favore chiarisci la tua domanda. Quando si dice "come identificatore di entità aziendale" questa non è una dichiarazione chiara. La maggior parte di noi pensa al business come cliente. Ma il tuo commento suggerisce che vuoi dire che è l'ideale per la chiave primaria per il tavolo. E la risposta a QUESTA domanda è che è sicuramente una buona idea per un PK quando lo stai definendo come una colonna autoincrementante e il PK ... purché tu non stia generando un GUID ... Vorrei anche aggiungere che mostrando a un cliente un numero di conto che è un valore auto incrementato va bene ...fintanto che non si tratta di un GUID – MER