Paesi di referenziamento tramite vincolo di chiave esterna

3

Per semplificare le spiegazioni: ho due tabelle: Table1 e Countries .

La tabella Countries contiene un bell'indicatore e alcune informazioni, come DisplayName, il codice ISO3166 ALPHA3 e il codice telefono (+49, + xx).

Table1 contiene clienti con una colonna Country .

È (in termini di usabilità, normalizzazione e senso umano comune) ok per fare riferimento da Table1.CountryId a Countries.Id tramite una chiave esterna invece di avere un campo Table1.Country nvarchar(255) e inserire un string in quello?

    
posta SeToY 26.04.2013 - 11:32
fonte

2 risposte

6

Non è tutto ok, devi assolutamente farlo in questo modo.

Solo la tabella Country dovrebbe contenere informazioni sui Paesi (come il nome). Tutte le altre tabelle che devono memorizzare un Paese devono semplicemente utilizzare CountryId e questa dovrebbe essere una chiave esterna per la tabella Country .

I motivi per farlo:

  • Evita la duplicazione. È uno spreco di spazio memorizzare il nome del paese e altre informazioni simili in più punti. Memorizzare il nome del paese sia nella tabella Country che altrove può richiedere molte più spazio. Supponiamo che tu abbia un milione di clienti provenienti da un centinaio di paesi diversi. Se memorizzi il nome del paese nella tabella dei clienti, hai appena aumentato lo spazio di archiviazione utilizzato per il nome del paese di un fattore di 10.000!
  • Rimuove l'ambiguità . Se si memorizza il nome del paese in due punti, si rischia di avere più versioni di un nome di paese. Potresti avere "USA", "Stati Uniti", "Stati Uniti", ecc. Sarà un disastro da affrontare. Basta usare un campo ID per evitare questo problema.
  • È efficiente . Forse la ragione di qualcuno per archiviare il paese per nome in Table1 sarebbe "bene, quindi non devo unirmi tutto il tempo per ottenere il nome del paese". Tuttavia, questa è una falsa economia. Un join basato su un ID numerico impostato come chiave esterna sarà banale, in termini di prestazioni. D'altra parte, se hai memorizzato il nome in entrambe le posizioni e hai quindi dovuto unirti in base al nome, sarebbe molto più lento.
risposta data 26.04.2013 - 11:43
fonte
4

Identificare i paesi con una chiave straniera è un'idea eccellente. L'utilizzo di qualsiasi cosa fuori ISO 3166 non è:

  • Lo standard consente di riutilizzare gli stessi codici alfabetici quando un paese subisce una modifica. Ad esempio, quando la Germania orientale e quella occidentale si unirono, le voci per entrambi i paesi furono ritirate. Il nuovo paese ha mantenuto i codici alfabetici della Germania occidentale (DE e DEU) e gli è stato assegnato un nuovo numero. Lo stesso è accaduto quando il Sud Sudan si è separato dal Sudan un paio di anni fa: il numero del Sudan è stato ritirato, sono stati emessi nuovi numeri per entrambi i paesi e il Sudan ha mantenuto i suoi vecchi codici alfabetici.

  • Alcuni codici alfabetici potrebbero essere riutilizzati per altri paesi in futuro. I codici per la Birmania (che si è ribattezzato Myanmar e ne hanno mantenuto il numero) sono riservati fino al 2040, quando tornano in piscina e potrebbero essere emessi in qualche altro paese.

  • I codici numerici sono stati storicamente unici, ma non avendo una copia dello standard, non posso dire con certezza se sono garantiti in questo modo. Con numeri in offerta infinita, immagino che non saranno ri-pubblicati, ma non scommetterei l'integrità del mio database su di esso. Lo standard segue i numeri assegnati dalla Divisione Statistiche delle Nazioni Unite e l'UNSD ha già riutilizzato il codice utilizzato per il Nordafrica spagnolo (un territorio) per il Sud Sudan.

Bottom line: mantieni la tua tabella con le proprie chiavi.

    
risposta data 26.04.2013 - 14:04
fonte

Leggi altre domande sui tag