Quali sono le migliori pratiche relative alle tabelle di ricerca nei database relazionali?

Le tabelle di ricerca (o tabelle di codici , come alcune persone le chiamano) sono in genere una raccolta dei possibili valori che possono essere forniti per una determinata colonna.

Ad esempio, supponiamo di avere una tabella di ricerca chiamata party(intesa per memorizzare informazioni sui partiti politici) che ha due colonne:

• party_code_idn, che contiene valori numerici generati dal sistema e (privo di significato del dominio aziendale ) funziona come surrogato della chiave reale.
• party_code, è la chiave reale o "naturale" della tabella perché mantiene valori che hanno connotazioni di dominio aziendale .

E diciamo che tale tabella conserva i dati che seguono:

 +----------------+------------+
 | party_code_idn | party_code |
 +----------------+------------+
 |              1 | Republican |
 |              2 | Democratic |
 +----------------+------------+

La party_codecolonna, che mantiene i valori "Repubblicano" e "Democratico", essendo la vera chiave della tabella, è impostata con un vincolo UNICO, ma ho facoltativamente aggiunto party_code_idne definito come il PK della tabella (anche se, logicamente parlando , party_codepuò funzionare come PRIMARY KEY [PK]).

Domanda

Quali sono le migliori pratiche per indicare i valori di ricerca dalle tabelle delle transazioni ? Devo stabilire riferimenti a CHIAVE ESTERA (FK) o (a) direttamente al valore naturale e significativo o (b) a valori surrogati?

Opzione (a) , ad esempio,

 +---------------+------------+---------+
 | candidate_idn | party_code |  city   |
 +---------------+------------+---------+
 |             1 | Democratic | Alaska  |
 |             2 | Republican | Memphis |
 +---------------+------------+---------+

ha le seguenti proprietà ¹ :

1. Leggibile per l'utente finale (+)
2. Facile da importare / esportare tra i sistemi (+)
3. Difficile cambiare il valore in quanto necessita di modifiche in tutte le tabelle di riferimento (-)
4. L'aggiunta di un nuovo valore non è costosa (=)

Penso che sia quasi come " passare per valore ", trarre un'analogia dalla chiamata di funzione nel gergo di programmazione dell'applicazione.

Opzione (b) , ad esempio,

 +---------------+----------------+---------+
 | candidate_idn | party_code_idn |  city   |
 +---------------+----------------+---------+
 |             1 |              1 | Alaska  |
 |             2 |              2 | Memphis |
 +---------------+----------------+---------+

ha le proprietà seguenti:

1. Non leggibile per l'utente finale (-)
2. Difficile import-export quanto dobbiamo de-referenziarlo (-)
3. Valori facili da modificare, poiché stiamo memorizzando solo riferimenti nelle tabelle delle transazioni (+)
4. L'aggiunta di un nuovo valore non è costosa (=)

È molto simile al " passaggio per riferimento ", se paragonato alla chiamata di funzione nel linguaggio di programmazione dell'app.

Import-Export può anche essere fatto in un modo diverso, cioè semplicemente popolando nuovamente la tabella di ricerca e quindi re-seed della colonna surrogata. Spero di capire bene, è qualcosa che ho appena sentito come una possibilità.

_{1. Notare che +, -e= indicare il beneficio di tali proprietà.}

Domanda

Abbastanza importante: c'è una differenza tra una ricerca (o un codice tabella di ) e un riferimento FK se utilizzeremo solo quest'ultimo approccio? Penso che funzionino allo stesso modo.

Risorse correlate

• Quanto sono importanti le tabelle di ricerca?

• Best practice con tabelle di codici o di ricerca

• Tabelle di ricerca Best practice Tabelle o enumerazioni DB

Con IDN, intendo che intendi un IDENTITY, SEQUENCEo AUTO_INCREMENTcampo? Dovresti dare un'occhiata qui e qui .

Nota, sezione 5 (Uso improprio di valori di dati come elementi di dati) del primo riferimento, sotto la figura 10

Ovviamente puoi avere una tabella separata per gli addetti alle vendite e quindi fare riferimento a essa usando una chiave esterna, preferibilmente con una semplice chiave surrogata come sales_person_id, mostrata sopra.

Quindi, questo esperto pensa che dovresti "deferire" le chiavi surrogate. È davvero una tecnica SQL di base e non dovrebbe causare problemi nell'SQL quotidiano. Sembra che ci sia un errore nella figura 10: il sales_person in SalesData dovrebbe essere una chiave surrogata (cioè un numero), non testo. Lo deduco dalla citazione sopra.

Ciò che dovresti evitare a tutti i costi è la tentazione (molto comune per i programmatori di database principianti) di commettere l'errore descritto nella sezione (1) Tabelle di ricerca comuni. Questo è comunemente chiamato l' approccio MUCK ( Massively Unified Code Key ) (non per caso :-) in particolare da Joe Celko , anche sarcasticamente noto come OTLT - One True Lookup Table ) e porta a tutti i tipi di difficoltà. I programmatori principianti sembrano ritenere che un singolo codice / ricerca / qualunque tabella sia "più pulita" e sarà più efficiente quando nulla potrebbe essere più lontano dalla verità.

Dal secondo riferimento sopra:

La normalizzazione elimina i dati ridondanti, rendendo così notevolmente più semplice il compito di imporre l'integrità dei dati, ma il processo di creazione di un MUCK è qualcosa di completamente diverso. I MUCK non eliminano i dati ridondanti, ma piuttosto un'eliminazione di quelli che PERCEPONO DI essere tabelle ridondanti, ma come dimostrerò, un minor numero di tabelle non equivale a semplicità.

Potresti anche dare un'occhiata al paradigma EAV ( Entity Attribute Value ) correlato che tratterò qui .

Esiste un terzo approccio che presenta alcuni dei vantaggi delle due opzioni: inserire un codice effettivo nella tabella dei codici. Con questo intendo una breve sequenza di caratteri che cattura l'essenza dell'intero valore ed è unica. Per il tuo esempio, potrebbe essere

Idn: 1
Name: Democrats
Code: D      (or DEM)

Il codice viene portato nelle tabelle transazionali come chiave esterna. È breve, intelligibile e in qualche modo indipendente dai dati "reali". Modifiche incrementali al nome non suggerirebbero una modifica del codice. Se i repubblicani dovessero decampare in massa , tuttavia, potrebbe essere necessario un cambio di codice, con i relativi problemi che un ID surrogato non dovrebbe sostenere.

Questo stile è stato definito una codifica abbreviazione. Posso consigliare la scrittura di Celko su questo. Google books contiene numerosi esempi. Cerca "Codifica Celko".

Altri esempi: codifica a 2 o 3 lettere per paesi, codifica a 3 lettere (GBP, USD, EUR) per i codici valuta. Breve, autoesplicativo e non cambia (e c'è un ISO per loro).