Utilizzo dei tasti primari Autoincrement come chiavi esterne

Vorrei usare la chiave di incremento automatico. Queste chiavi sono completamente prive di significato e non sono in alcun modo collegate all'azienda o all'ambiente che potrebbe cambiarle, e questo le rende molto più facili da usare come chiavi esterne in altre tabelle.

Non importa quanto l'azienda prometta che alcune chiavi significative non cambieranno mai, o che l'algoritmo che sta creando le chiavi rimarrà lo stesso per sempre, queste cose potrebbero cambiare, e quando lo faranno ci saranno problemi se non lo facessi Ricordati di impostare aggiornamenti a cascata o qualcosa del genere.

Una chiave primaria di autoincremento viene creata in modo programmatico come una volta che si calcola. Ed è proprio come (se non di più) unico.
Non ho mai riscontrato una situazione in cui le persone abbiano avuto qualche ripensamento sull'usarli come chiavi esterne (in cui una chiave esterna sulla chiave primaria è appropriata, com'è normale).

we have the fields 'id' (autoincrement primary key), 'productCode' (unique), 'Description'.

... relationship to a transactions table. What field should be used as foreign key, the 'autoid' or the product code?

Se il codice prodotto (la chiave naturale per questa tabella) è unico e invariato rispetto alla durata intera di un prodotto, allora nessuna differenza che utilizzi come chiave primaria (anche se, naturalmente, deve essere la chiave primaria per poter utilizzare le chiavi esterne che fanno riferimento a essa!).

Se c'è una qualsiasi possibilità che il Codice prodotto possa cambiare, usa la chiave primaria [surrogata].

Personalmente, non faccio mai una tabella senza una chiave primaria autoincrement, e la uso sempre come chiave esterna. Non me ne sono mai pentito. Le tabelle denormalizzate hanno il loro uso, ma anche se è il tipo di tabella che probabilmente sarebbe ok denormalizzata, aggiungo ancora un PK autoincrement. Ho persino impostato un PK autoincrement per le tabelle che hanno una colonna ID univoca e garantita "garantita" (che diventa solo informativo).

Perché?

1. Arbritrarity. L'utente non ha motivo di preoccuparsi o di conoscerlo. Quindi, non lo cambieranno e non spezzeranno tutto.
2. Correttezza garantita. Se qualcuno grassa le dita, l'ID univoco "garantito" fornito dall'utente, e in qualche modo non si accorge per un po ', può cambiarlo senza rompere tutto.
3. espandibilità. Tra qualche anno, c'è una buona possibilità che qualcuno vorrà unirsi a quel tavolo.
4. Unicità garantita. "Che cosa vuoi dire che c'è più di un John Foobar?!"
5. Semplicità delle query. È molto più facile ricordare il nome della colonna di chiave esterna quando è "id" di quando è "LastName" in questa tabella, "RegistrationNo" in quella tabella ...

Il 100% del mondo ha perso i dati ad un certo punto e quando ciò accade, può essenzialmente isolare la tabella basata su FK. I ragazzi di DB ti prometteranno che questo non può mai accadere e promuove tutti i tipi di funzionalità di ripristino e backup e concetti di registrazione, ma succede. Direi che è una buona dose 50/50 nella mia esperienza di sistemi aziendali che modificano la logica di business che influisce sulla struttura chiave rispetto ai problemi di dati che influiscono sulla struttura chiave. Devi ricordare che questo include una cattiva logica di business che inserisce dati inutili che ora hanno un grande muk con le tue chiavi auto incrementate.

Entrambe le opzioni possono gestire l'integrità, ad esempio ACID, ugualmente bene e venire con le proprie sfide. Davvero la situazione in cui si dovrebbe guardare per vedere cosa funziona meglio. Direi che è più facile ripristinare l'integrità dei dati completamente controllabili che è logico rispetto alle chiavi autoincrementate.