Quanto sono importanti le tabelle di ricerca?

La risposta dipende un po' se sei limitato a freeware come PostGreSQL (non completamente conforme a SQL), o se stai pensando a SQL (ad es. conforme a SQL) e database di grandi dimensioni.

Conforme a SQL, Architettura aperta database, dove ci sono molte app che utilizzano un database e molti utenti che utilizzano strumenti di report diversi (non solo le app) per accedere ai dati, standard, normalizzazione e requisiti di architettura aperta sono importanti.

Nonostante le persone che tentano di cambiare la definizione di "normalizzazione", ecc. per soddisfare il loro scopo in continua evoluzione, la normalizzazione (la scienza) non è cambiata.

se hai valori di dati come {Open; Closed; etc } ripetuto nelle tabelle di dati, ovvero duplicazione dei dati , un semplice errore di normalizzazione:se quei valori cambiano, potresti dover aggiornare milioni di righe, il che è un design molto limitato.
- Tali valori dovrebbero essere normalizzati in una tabella di riferimento o di ricerca, con un breve CHAR(2) PK:
```
O  Open
C  Closed
U  [NotKnown]
```
- I valori dei dati {Open;Closed;etc } non sono più duplicati nei milioni di righe. Risparmia anche spazio.
- il secondo punto è la facilità di modifica, se Closed sono stati modificati in Expired , ancora una volta, è necessario modificare una riga e ciò si riflette nell'intero database; mentre nei file non normalizzati è necessario modificare milioni di righe.
- Aggiunta di nuovi valori di dati , per esempio. (H,HalfOpen ) si tratta semplicemente di inserire una riga.
in Architettura aperta termini, la tabella di ricerca è una tabella normale. Esiste nel catalogo [conforme a SQL]; purché il FOREIGN KEY è stata definita la relazione, anche lo strumento di report può trovarlo.
ENUM è un non SQL, non usarlo. In SQL "enum" è una tabella di ricerca.
Il punto successivo riguarda il significato della chiave.
- Se la chiave non ha significato per l'utente, bene, usa un {INT;BIGINT;GUID;etc } o qualunque cosa sia adatta; non numerarli in modo incrementale; consenti "lacune".
- Ma se la chiave è significativa per l'utente, non utilizzare un numero privo di significato, usa una chiave relazionale significativa.
Ora alcune persone entreranno in tangenti per quanto riguarda la permanenza dei PK. Questo è un punto separato. Sì, certo, usa sempre un valore stabile per una PK (non "immutabile", perché non esiste una cosa del genere e una chiave generata dal sistema non fornisce l'univocità della riga).
- {M,F } è improbabile che cambi
- se hai utilizzato {0,1,2,4,6 }, beh, non cambiarlo, perché vorresti farlo. Questi valori avrebbero dovuto essere privi di significato, ricorda, solo una chiave significativa deve essere cambiata.
- se usi chiavi significative, usa codici alfabetici brevi, che gli sviluppatori possano facilmente capire (e da cui dedurre la lunga descrizione). Lo apprezzerai solo quando codifichi SELECT e renditi conto che non devi JOINs ogni tabella di ricerca. Anche gli utenti esperti lo apprezzano.
Poiché le PK sono stabili, in particolare nelle tabelle di ricerca, puoi codificare in sicurezza:

WHERE status_code = 'O' -- Open

Non devi JOINs la tabella di ricerca e ottenere il valore dati Open , come sviluppatore, dovresti sapere cosa significano le PK di ricerca.

Infine, se il database era di grandi dimensioni e supportava funzioni BI o DSS o OLAP oltre a OLTP (come possono fare i database correttamente normalizzati), la tabella di ricerca è in realtà una dimensione o un vettore, in Dimension-Fact analisi. Se non fosse presente, dovrebbe essere aggiunto, per soddisfare i requisiti di quel software, prima che tali analisi possano essere montate.

Se esegui questa operazione sul tuo database dall'inizio, non dovrai aggiornarlo (e il codice) in seguito.

Il tuo esempio

SQL è un linguaggio di basso livello, quindi è ingombrante, soprattutto quando si tratta di JOINs . Questo è ciò che abbiamo, quindi dobbiamo semplicemente accettare l'ingombro e affrontarlo. Il tuo codice di esempio va bene. Ma le forme più semplici possono fare la stessa cosa.

Uno strumento di report genererebbe:

SELECT p.*,
       s.name
    FROM posts  p, 
         status s
    WHERE p.status_id = s.status_id 
    AND   p.status_id = 'O'

Un altro esempio

Per i sistemi bancari, dove utilizziamo codici brevi che sono significativi (poiché sono significativi, non li cambiamo con le stagioni, li aggiungiamo solo ad essi), data una tabella di ricerca come (scelta con cura, simile ai codici paese ISO) :

Eq   Equity
EqCS Equity/Common Share
OTC  OverTheCounter
OF   OTC/Future

Un codice come questo è comune:

WHERE InstrumentTypeCode LIKE "Eq%"

E gli utenti della GUI sceglierebbero il valore da un menu a discesa che mostra
{Equity/Common Share;Over The Counter },
non {Eq;OTC;OF }, non {M;F;U }.
Senza una tabella di ricerca, non puoi farlo né nelle app né nello strumento di report.