L'uso di char come chiave primaria / esterna è un no no?

Question

Considera che ci sono un sacco di tabelle che si collegano a " paesi " o "quotazioni" tabelle.

Per rendere i dati più facili da leggere, vorrei rendere il campo CHAR con il prefisso internazionale (ad es. US, GB, AU) e il codice valuta (USD, AUD) una chiave primaria in ognuna di quelle 2 tabelle e tutte le altre tabelle useranno questo CHAR come chiave anticipata.

Il database è mysql con motore innodb.

Causerà problemi di prestazioni? È qualcosa che dovrei evitare?

Answer 1

Le prestazioni non sono proprio il problema principale, almeno non per me. Il problema riguarda più i surrogati rispetto alle chiavi naturali.

I codici paese non sono statici. Possono e cambiano. I paesi cambiano nome (ad esempio l'Etiopia in Eritrea). Nascono (ad es. La rottura della Jugoslavia o dell'Unione Sovietica) e cessano di esistere (ad es. Germania occidentale e orientale). Quando ciò accade, il codice ISO standard cambia.

Altro in Cambiamenti di nome dal 1990: Paesi, città e altro

Le chiavi surrogate tendono ad essere migliori perché quando si verificano questi eventi le chiavi non cambiano, lo fanno solo le colonne nella tabella di riferimento.

Per questo motivo sarei più propenso a creare tabelle di paesi e valute con una chiave primaria int.

Detto questo, i campi chiave varchar useranno più spazio e avranno alcuni svantaggi prestazionali che probabilmente non saranno un problema a meno che non si stiano eseguendo un numero enorme di query.

Per completezza, ti consigliamo di fare riferimento a Errori di sviluppo del database realizzati di AppDevelopers .

Answer 2

Il link di James Skidmore è importante da leggere.

Se ti stai limitando ai codici Paese e valuta (rispettivamente 2 e 3 caratteri), potresti benissimo essere in grado di cavartela dichiarando le colonne char (2) e char (3).

Immagino che non sarebbe un no-no. Se stai utilizzando una codifica di caratteri a 8 bit, stai visualizzando le colonne delle dimensioni di smallint o mediumint, rispettivamente.

Answer 3

La mia risposta è che non esiste una risposta chiara. Scegli un approccio all'interno del tuo progetto e sii coerente. Entrambi hanno i loro vantaggi e svantaggi.

@cletus ha un buon punto sull'uso delle chiavi generate, ma quando ti imbatti in una situazione in cui i dati sono relativamente statici, come i codici paese, l'introduzione di una chiave generata per loro sembra eccessivamente complessa. Nonostante la politica del mondo reale, la visualizzazione e la scomparsa dei codici dei paesi non sarà un grosso problema per la maggior parte dei problemi aziendali (ma se i tuoi dati riguardano attivamente tutti i 190-210 paesi, segui questi consigli).

L'uso universale delle chiavi surrogate è una strategia valida e popolare. Ma ricorda, arriva in risposta alla modellazione di database usando chiavi naturali per tutto. Ack! Apri un libro di database di 15 anni. L'uso di chiavi naturali ovunque ti porta sicuramente in situazioni difficili, poiché la comprensione iniziale dei domini problematici si rivela errata. Vuoi avere coerenza nelle tue pratiche di modellazione, ma usare tecniche diverse per situazioni chiaramente diverse va bene.

Sospetto che le prestazioni per la maggior parte dei database moderni su var (2) chiavi esterne saranno le stesse (o migliori) dei campi int. I database supportano da anni chiavi esterne testuali.

Dato che non abbiamo altre informazioni sul progetto, se si preferisce utilizzare i codici paese come chiavi esterne e si ha la possibilità di farlo, direi che va bene. Sarà più facile lavorare con i dati. È un po 'contro le pratiche attuali, ma, in questo caso, non ti riporterà in qualche angolo.