utilizzando le chiavi primarie incrementali sui dati del mondo reale

Il solo ed unico lavoro è la chiave primaria. Chiedigli di fare qualcos'altro e all'improvviso ha motivi per cambiare che non hanno nulla a che fare con l'essere la chiave primaria.

Un famoso esempio di questo è stato quando Steve Jobs ha scoperto che sarebbe stato elencato come impiegato # 2 dopo Wozniak al primo posto. Non poteva prenderlo così ha insistito affinché fosse cambiato. Piuttosto che retrocedere, Woz Jobs voleva essere impiegato # 0. Bene, il sistema non potrebbe farlo. Jobs non era soddisfatto.

Perché è stato un problema? Perché il sistema mostrava le informazioni strutturali interne al cliente. È strano come far sapere al cliente il nome di un tavolo o memorizzare il secondo nome nel 4 ° campo. Non vi è alcun motivo per cui il cliente sappia o si preoccupi di ciò. Ma se glielo fai sapere, troveranno un modo per prendersene cura. Ora devi cambiare, o non puoi cambiare, cose che non avrebbero dovuto essere un problema in primo luogo.

Infatti, consiglierei di iniziare qualsiasi numero ID di dipendente pubblicato con un numero casuale senza significato, anche se lo si incrementa, solo per impedire ai programmatori che lo vedono di pensare che è uguale alla chiave primaria.

Se hai bisogno delle parole di fantasia per questo qui sono: questo è l'incapsulamento di base, l'occultamento delle informazioni. È il modo migliore per garantire il disaccoppiamento.

La chiave primaria ha lo scopo di identificare univocamente un record. Se il record è qualcosa che può essere identificato nel mondo reale da qualche attributo (un dipendente si adatta sicuramente a tale descrizione), quindi scegli qualcosa che è immutabile nel tempo e nello spazio. GUID potrebbe essere una buona scelta, ma in alcuni casi può essere un po 'troppo grande.

Uno dei motivi per cui non è una buona pratica utilizzare l'autoincrement come ID per gli elementi che possono essere identificati esternamente è che potrebbe causare problemi quando i dati vengono migrati da un database a un altro o quando è necessario integrarli due sistemi. Immagina di avere due sistemi che funzionano con lo stesso set di dipendenti. Se si utilizza l'autoincremento come chiave primaria, non ci sarebbe modo di mappare in modo univoco i dipendenti da un sistema a dipendenti in un altro. Tuttavia, se i dipendenti sono identificati da un codice univoco, non avresti quel problema e potresti integrare questi due sistemi piuttosto facilmente.

Usa l'autoincremento con record che sono numerosi e non possono essere identificati da qualcosa di diverso dall'intero record (in alcuni casi, nemmeno da quello). Gli esempi potrebbero essere alcune misurazioni, identificate dall'ID del dispositivo di misurazione, dal timestamp della misurazione e dal valore misurato o dalle tabelle di riferimento incrociato che possono avere più record che puntano agli stessi record nelle tabelle di riferimento.

I PK a incremento automatico, interi o in altro modo, non sono intrinsecamente problematici. "La migliore pratica" per un PK è che non si rapporta agli attributi del mondo reale dell'oggetto. Il PK esiste per identificare univocamente un'entità nel caso in cui gli altri attributi cambino - anche gli attributi apparentemente permanenti, che sono soggetti a correzioni.

Il PK non dovrebbe "mai" aver bisogno di cambiare, salvo una revisione architettonica o la migrazione dei dati. Quindi, fintanto che il tuo PK si adatta a quel conto, non è "sbagliato" o "cattivo" per qualsiasi entità, intrinsecamente, reale o altro.

Detto questo, ci possono essere delle difficoltà quando si usa un PK autoincrementante. Vale a dire, l'unicità è più difficile da raggiungere tra gli host. Nel caso in cui i dati host A e B debbano combinare i loro pool user , o l'evento che i nuovi dati ospitano da C a Z devono essere aggiunti, c'è una sfida abbastanza grande lì se non lo avevate già programmato. D'altra parte, se utilizzi UUID semi-casuali o qualcosa del genere, con macchine, datetime e componenti casuali, probabilmente stai eseguendo la migrazione, l'unione o l'aggiunta di host senza problemi.

Il vantaggio principale dei PK auto-incrementati è l'efficienza della ricerca. Un vantaggio che sta calando un po 'ogni anno, attenzione ...