Come chiamare la chiave surrogata quando il nome logico è già occupato dalla chiave aziendale

Se hai ancora la possibilità di prendere questo tipo di decisioni, ti consiglio vivamente di scegliere una convenzione di denominazione strict per le chiavi surrogate come Tablename<suffix> , dove <suffix> è un testo fisso come "Id" o "_Id" o "SKey" o "_PK" come "chiave primaria". Quale suffisso tu scelga non ha molta importanza, se ti aspetti di nominare collisioni con alcune chiavi aziendali, sceglierne una che eviti questo. L'obiettivo dovrebbe essere quello di rendere più facile la creazione di codice generico basato su tale convenzione e di aver bisogno di meno documentazione poiché la convenzione significa sempre la stessa.

Tuttavia, potresti aver già scelto una convenzione, iniziato a costruire il tuo sistema attorno ad esso con alcuni dati e applicazioni. Successivamente, estendi il sistema in seguito e trova una collisione di nomi con qualche chiave aziendale. In questa situazione, potrebbe essere più semplice selezionare un nome diverso per la colonna della chiave aziendale, anche se corrisponde alle convenzioni delle società solo al 95% anziché al 100%.

Si chiama chiave naturale o aziendale.

In relational model database design, a natural key (also known as business key) is a key that is formed of attributes that already exist in the real world. For example, a US citizen's social security number could be used as a natural key. In other words, a natural key is a candidate key that has a logical relationship to the attributes within that row. A natural key is sometimes called domain key.

Aggiornamento:

Se nel tuo caso esiste già una chiave aziendale ed è già nota come PRODUCT_ID dagli uomini d'affari, un buon nome alternativo per il surrogato che intendi creare sarebbe PRODUCT_NUMBER o PRODUCT_NUM .

PRODUCT_KEY non ha un nome così bello per me perché l'altra colonna è anche una chiave, una chiave candidata. La surrogata sarà la chiave primaria e la chiave naturale avrà un indice univoco basato su di essa, rendendola una chiave aziendale che verrà utilizzata per le ricerche. Quindi chiamare la surrogata PRODUCT_KEY sarebbe come chiamarlo PRODUCT_PK (leggermente migliore).

Vorrei andare per PRODUCT_NUMBER o PRODUCT_NUM .

Se l'ID prodotto non cambia, utilizzare la chiave aziendale / naturale esistente come chiave primaria. Non c'è bisogno di una chiave surrogata.

Un'alternativa, se sei ancora nella fase di progettazione del tuo database, è la denominazione della chiave aziendale ProductCode e la gestione della convenzione per il nome della chiave primaria.