SQL liste static dati / di ricerca IDENTIFIER

Question

Per quanto riguarda la struttura della tabella dati statici. Avere dati statici nelle tabelle come mostrato:

• Valute (codice, nome). Esempio Row: USD, Stati Uniti Dollaro
• Paesi (codice, nome). Esempio Row: DE, Germania
• XXXObjectType (codice, nome, ... altri attributi)
• ...

Ha senso avere un'altra colonna (intero) come chiave primaria in modo che tutti i riferimenti di chiave esterna userebbero?

possibili soluzioni:

1. Usa INTEGER supplementare come PK e FK
2. Utilizza il codice (di solito CHAR (N), dove N è piccolo), come PK e FK
3. Utilizza il codice solo se meno certa dimensione ... Che taglia?
4. Altro _______

Quale sarebbe il vostro suggerimento? Perché?

Io di solito usato colonne INT IDENTITY, ma molto spesso con il codice corto è abbastanza buono da mostrare all'utente nell'interfaccia utente, nel qual caso l'interrogazione avrebbe un JOIN meno.

Answer 1

Un'identità INT non è assolutamente necessario qui. utilizzare invece il mnemonica 2 o 3 cifre. Se si dispone di un'entità che non ha piccolo, struttura unica, si dovrebbe quindi considerare l'utilizzo di una chiave sintetica. Ma i codici di valuta e codici dei paesi non sono il tempo per farlo.

Una volta ho lavorato su un sistema in cui qualcuno in realtà aveva un tavolo di anni, e ogni anno ha avuto un YearID. E, fedele alla forma, il 2001 è stato l'anno 3, e il 2000 è stato l'anno 4. Ha fatto tutto il resto del sistema di così molto più difficile da comprendere e query per, ed è stato per niente.

Answer 2

Se si utilizza un INT ID o di un CHAR, integrità referenziale è conservato in entrambi i casi.
Un INT è lungo 4 byte, quindi è dimensioni uguali come CHAR (4); se si utilizza CHAR (x) dove x <4, la chiave CHAR sarà più breve di un INT uno; se si utilizza CHAR (x) dove x> 4, la chiave CAR sarà maggiore di un INT uno; per le chiavi breve non solitamente senso utilizzare VARCHAR, in quanto quest'ultimo presenta un aereo 2 byte. In ogni caso, quando si parla di tabelle con - dicono - 500 record, l'overhead totale di un CHAR (5) nel corso di un tasto INT sarebbe solo 500 byte, un valore esilarante per il database in cui alcune tabelle potrebbero avere milioni di dischi
. Considerando che i paesi e valute (ad esempio) sono in numero limitato (a poche centinaia, al massimo) non si ha reale di guadagno utilizzando un INT ID al posto di un CHAR (4); inoltre, un CHAR (4) chiave può essere più facile da ricordare per l'utente finale, e può facilitare la vostra vita quando si deve eseguire il debug / testare SQL e / o dati.
Pertanto, anche se io di solito uso una chiave di ID INT per la maggior parte delle mie tabelle, in diverse circostanze ho scegliere di avere un PK / FK fatto di caratteri: paesi, lingue, valute sono tra quei casi

.