Hur viktiga är uppslagstabeller?

Svaret beror lite på om du är begränsad till gratisprogram som PostGreSQL (inte helt SQL-kompatibel), eller om du funderar på SQL (dvs. SQL-kompatibel) och stora databaser.

I SQL-kompatibel, Öppen arkitektur databaser, där det finns många appar som använder en databas och många användare som använder olika rapportverktyg (inte bara apparna) för att komma åt data, standarder, normalisering och krav på öppen arkitektur är viktiga.

Trots de människor som försöker ändra definitionen av "normalisering" etc. för att passa deras ständigt föränderliga syfte, har normalisering (vetenskapen) inte förändrats.

om du har datavärden såsom {Open; Closed; etc } upprepas i datatabeller, det vill säga dataduplicering , ett enkelt normaliseringsfel:om du ändrar dessa värden kan du behöva uppdatera miljontals rader, vilket är mycket begränsad design.
- Sådana värden bör normaliseras till en referens- eller uppslagstabell, med en kort CHAR(2) PK:
```
O  Open
C  Closed
U  [NotKnown]
```
- datavärdena {Open;Closed;etc } dupliceras inte längre i miljontals rader. Det sparar också utrymme.
- den andra punkten är enkel ändring, om Closed ändrades till Expired , återigen, en rad måste ändras, och det återspeglas i hela databasen; medan i de onormaliserade filerna måste miljontals rader ändras.
- Lägger till nya datavärden , t.ex. (H,HalfOpen ) är då helt enkelt en fråga om att infoga en rad.
i Öppen arkitektur termer är Lookup-tabellen en vanlig tabell. Det finns i den [SQL-kompatibla] katalogen; så länge som FOREIGN KEY relation har definierats, kan rapportverktyget också hitta det.
ENUM är en icke-SQL, använd den inte. I SQL är "enum" en Lookup-tabell.
Nästa punkt handlar om nyckelns meningsfullhet.
- Om nyckeln är meningslös för användaren, okej, använd en {INT;BIGINT;GUID;etc } eller vad som passar; numrera dem inte stegvis; tillåt "luckor".
- Men om nyckeln är meningsfull för användaren, använd inte ett meningslöst nummer, använd en meningsfull relationsnyckel.
Nu kommer en del människor att komma in på tangenter när det gäller PKs beständighet. Det är en separat punkt. Ja, naturligtvis, använd alltid ett stabilt värde för en PK (inte "oföränderlig", eftersom det inte finns något sådant, och en systemgenererad nyckel ger inte radunikitet).
- {M,F } kommer sannolikt inte att ändras
- om du har använt {0,1,2,4,6 }, ändra det inte, varför skulle du vilja det. Dessa värden var tänkta att vara meningslösa, kom ihåg att bara en meningsfull nyckel behöver ändras.
- om du använder meningsfulla nycklar, använd korta alfabetiska koder, som utvecklare lätt kan förstå (och härleda den långa beskrivningen från). Du kommer bara att uppskatta detta när du kodar SELECT och inser att du inte behöver JOIN varje uppslagstabell. Även avancerade användare uppskattar det.
Eftersom PK:er är stabila, särskilt i uppslagstabeller, kan du säkert koda:

WHERE status_code = 'O' -- Open

Du behöver inte JOIN uppslagstabellen och skaffa datavärde Open , som utvecklare ska du veta vad Lookup PK betyder.

Sist, om databasen var stor och stödde BI- eller DSS- eller OLAP-funktioner utöver OLTP (som korrekt normaliserade databaser kan), så är Lookup-tabellen faktiskt en dimension eller vektor, i Dimension-Fact analyser. Om den inte fanns där skulle den behöva läggas till, för att uppfylla kraven för den programvaran, innan sådana analyser kan monteras.

Om du gör det med din databas från början behöver du inte uppgradera den (och koden) senare.

Ditt exempel

SQL är ett lågnivåspråk, så det är besvärligt, särskilt när det kommer till JOINs . Det är vad vi har, så vi måste bara acceptera belastningen och ta itu med den. Din exempelkod är bra. Men enklare former kan göra samma sak.

Ett rapportverktyg skulle generera:

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

Ett annat exempel

För banksystem, där vi använder korta koder som är meningsfulla (eftersom de är meningsfulla ändrar vi dem inte med årstiderna, vi lägger bara till dem), givet en uppslagstabell som (noggrant utvald, liknande ISO-landskoder) :

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

Kod som denna är vanlig:

WHERE InstrumentTypeCode LIKE "Eq%"

Och användarna av GUI skulle välja värdet från en rullgardinsmeny som visar
{Equity/Common Share;Over The Counter },
inte {Eq;OTC;OF }, inte {M;F;U }.
Utan en uppslagstabell kan du inte göra det, varken i apparna eller i rapportverktyget.