Come definire un ID naturale nel database?

Di solito, si potrebbe provare prima a trovare una chiave naturale, proveniente dal dominio del problema; per esempio. un codice EAN / UPC per i prodotti o il SSN per le persone.

Quando non c'è una chiave naturale ovvia, l'ID artificiale è solo un numero in conteggio, e quelle lacune dopo l'eliminazione non sono considerate problematiche, perché l'ID è comunque privo di significato.

Suggerimento: la significatività non può essere creata artificialmente.

Qual è il problema con le lacune nel database quando si utilizzano gli ID da 1 an? Se ti preoccupi veramente delle lacune, potresti aggiungere nuovi manuali all'interno di quelle. (Nel tuo esempio il prossimo nuovo manuale otterrebbe l'ID 2, 3, ..., 32, 34). Oppure puoi salvare una lista / pila di ID dai manuali cancellati e ogni volta che aggiungi una nuova apri il prossimo ID dalla lista / pila. Questo ti farà risparmiare un po 'di tempo.

Inoltre, un ID non è pensato per essere significativo, è solo per avere un modo veloce per distinguere tra diversi manuali, quindi gli ID dovrebbero essere unici. Hai detto che ogni manuale ha un nome che dovrebbe essere già abbastanza significativo e se due manuali hanno lo stesso nome hanno almeno ID diversi.

La definizione di "significativo" o anche "non complicato" è lontana dall'essere oggettiva, IMHO. Anche significativo potrebbe dipendere molto dai dati che stai memorizzando nel tuo database.

Come dichiarato da mcwise, lo scopo di un ID è di essere unico e non significativo. Devi davvero usare un id manuale? L'ID generato automaticamente ti impedisce persino di sapere che ci sono degli spazi vuoti e assicurerà sempre che gli ID siano unici.

Se assolutamente vuoi un manuale univoco e un ID significativo, prova a trovare un campo che sarà sempre unico nella tua base (ad esempio e-mail per gli utenti in un sito web) o generarne uno da più campi in cui sai che la combinazione sarà unica (ad esempio nome-cognome-data di nascita-luogo di nascita)

Un identificatore significativo per l'uomo e un identificatore significativo per la macchina possono essere due cose separate: entrambi richiedono l'unicità a causa della natura intrinseca del problema:

Given X, how can I find the manual I need?

Gli identificatori dovrebbero essere dati per gli umani, piuttosto che generati dagli umani. Gli esseri umani sono cattivi nella creazione di identificatori univoci, ma i computer sono buoni (o almeno veloci).

Idealmente, avrai una sorta di meccanismo di ricerca quando stai cercando un manuale. Non dovrai ricordare alcun numero casuale a 16 byte o codice QR, perché il computer genererà un elenco di tutti i manuali attualmente salvati per te quando cerchi "richiede assemblaggio" o "batterie non incluse" e fornisci link a loro per te.

Detto questo, è spesso un vantaggio avere una chiave unica che non ha alcun significato. Chiamalo "UniqueID", "MagicKey" o qualsiasi altra cosa ti piaccia, ma ricorda che non ha alcun significato al di fuori del tuo database. In questo modo, se il significato di qualcosa che ha a che fare con il manuale cambia in un modo che non ti aspetti, non devi cambiare la chiave.

Questo è il motivo per cui Username è una scelta scadente per una chiave esterna in un database. Se un utente cambia il suo nome utente (se è basato sul suo cognome e si sposano, potrebbe voler cambiarlo), hai molto lavoro da fare nel tuo database.

Se scegli invece un "UserID" senza significato e l'utente cambia il nome utente, hai solo la modifica da apportare in un posto e tutti sono felici.

Significativo e unico coesistono appena in un unico luogo. Per quanto mi riguarda, utilizzo un numero incrementale automatico generato come ID quando si tratta di migliaia di record.

Nel caso in cui si utilizzi un numero incrementale come ID, c'è un campo in più che determina se il manuale esiste o viene cancellato. Tutto quello che devi fare è nell'istruzione select menzionare un'altra condizione nella clausola where.
Un altro vantaggio dell'utilizzo di questo è che non è necessario preoccuparsi di quale ID deve essere assegnato a una nuova voce manuale che il sistema si prenderà cura di esso.
Parlando della logica da usare per assegnare gli ID, dipende esclusivamente dal programmatore. La logica che è più facile per lui.

La tua preoccupazione per i numeri mancanti e gli ID significativi è fuorviata.

Il numero ID deve essere un numero one-up generato dal computer. Chiedere all'utente di scegliere un numero invita troppi problemi. Ci può essere un errore di battitura, puoi saltare un numero o duplicare un numero. È possibile scrivere software per cercare questi problemi, ma è più facile avere il database a occuparsi della creazione di record.

Se un manuale viene distrutto perché non è più necessario, non si desidera riciclare il numero. Immaginate se qualcuno avesse una procedura in cui diceva di ottenere il manuale 7 e completare l'attività a pagina 99 in modo che i backup del computer possano essere ripristinati. Ma il manuale 7 riguarda ora gli allarmi antifumo e ha solo 10 pagine. Se uno viene sostituito, dovresti avere un campo che dice all'utente che è sparito e che il manuale aggiornato è ora il numero 50.

Utilizzerai i titoli reali dei manuali come un campo nel database. In questo modo quando ci sono centinaia di loro possono essere cercati con parole chiave. Immagina quanto sarebbe difficile parlare di libri se non ci fossero titoli, solo i numeri ISBN.