Va bene avere una chiave esterna come chiave primaria?

Ho tabella “Utente” (username, password) e tabella “Profilo” (profileId, gender, dateofbirth, …). Attualmente sto usando questo approccio: ogni record del profilo ha un campo chiamato “userId” come chiave esterna che si collega alla tabella User. Quando un utente si registra, il suo record del profilo viene creato automaticamente. Sono confuso con il suggerimento del mio amico: avere il campo “userId” come chiave esterna e primaria ed eliminare il campo “profileId”. Quale approccio è migliore?

Le chiavi esterne sono quasi sempre “Consenti duplicati”, che le renderebbe non idonee come chiavi primarie.

Invece, trova un campo che identifica in modo univoco ogni record nella tabella o aggiungi un nuovo campo (un numero intero a incremento automatico o un GUID) per fungere da chiave primaria.

L’unica eccezione a questa sono le tabelle con una relazione uno-a-uno, in cui la chiave esterna e la chiave primaria della tabella collegata sono la stessa cosa.

Le chiavi primarie devono sempre essere univoche, le chiavi esterne devono consentire valori non univoci se la tabella è una relazione uno-a-molti. È perfettamente utile utilizzare una chiave esterna come chiave primaria se la tabella è collegata da una relazione uno a uno, non una relazione uno-a-molti. Se vuoi che lo stesso record utente abbia la possibilità di avere più di 1 record relativo al profilo, vai con una chiave primaria separata, altrimenti rimani con ciò che hai.

Generalmente è considerata una ctriggers pratica avere una relazione uno a uno. Questo perché potresti semplicemente avere i dati rappresentati in una tabella e ottenere lo stesso risultato.

Tuttavia, ci sono casi in cui potresti non essere in grado di apportare queste modifiche alla tabella a cui stai facendo riferimento. In questo caso non ci sono problemi nell’usare la chiave esterna come chiave primaria. Potrebbe essere utile avere una chiave composta composta da una chiave primaria univoca che incrementa automaticamente e la chiave esterna.

Attualmente sto lavorando a un sistema in cui gli utenti possono accedere e generare un codice di registrazione da utilizzare con un’app. Per ragioni che non entrerò non sono in grado di aggiungere semplicemente le colonne richieste alla tabella degli utenti. Quindi sto andando giù per un percorso uno a uno con la tabella dei codici.

Sì, una chiave esterna può essere una chiave primaria nel caso di una relazione uno a uno tra quelle tabelle

Non lo farei. Manterrei il profileID come chiave primaria del Profile della tabella

Una chiave esterna è solo un vincolo referenziale tra due tabelle

Si potrebbe obiettare che una chiave primaria è necessaria come objective di qualsiasi chiave esterna che si riferisce ad essa da altre tabelle. Una chiave esterna è un insieme di una o più colonne in qualsiasi tabella (non necessariamente una chiave candidata, per non parlare della chiave primaria, di quella tabella) che può contenere il valore (s) trovato nella (e) colonna (i) chiave primaria di altro tavolo. Quindi dobbiamo avere una chiave primaria per abbinare la chiave esterna. O dobbiamo? L’unico scopo della chiave primaria nella coppia chiave primaria / chiave esterna è fornire un join non ambiguo: per mantenere l’integrità referenziale rispetto alla tabella “foreign” che contiene la chiave primaria di riferimento. Ciò assicura che il valore a cui fa riferimento la chiave esterna sia sempre valido (o null, se consentito).

http://www.aisintl.com/case/primary_and_foreign_key.html

Dipende dal business e dal sistema.

Se il tuo ID utente è unico e sarà sempre univoco, puoi utilizzare userId come chiave primaria. Ma se vuoi espandere il tuo sistema, renderà le cose difficili. Ti consiglio di aggiungere una chiave esterna all’utente della tabella per creare una relazione con il profilo della tabella anziché aggiungere una chiave esterna nel profilo della tabella.

Sì, è legale avere una chiave primaria come chiave esterna. Questo è un costrutto raro, ma vale per:

  • una relazione 1: 1. Le due tabelle non possono essere unite in una a causa di permessi e privilegi diversi si applicano solo a livello di tabella (a partire dal 2017, tale database sarebbe dispari).

  • una relazione 1: 0..1. Il profilo potrebbe o potrebbe non esistere, a seconda del tipo di utente.

  • le prestazioni sono un problema e il design funziona come una partizione: la tabella dei profili viene raramente utilizzata, ospitata su un disco separato o ha un criterio di sharing diverso rispetto alla tabella degli utenti. Non avrebbe senso se la memoria della sottolineatura è colonnare.