Hvor vigtige er opslagstabeller?

Svaret afhænger lidt af, om du er begrænset til freeware såsom PostGreSQL (ikke fuldt SQL-kompatibel), eller om du tænker på SQL (dvs. SQL-kompatibel) og store databaser.

I SQL-kompatibel, Åben arkitektur databaser, hvor der er mange apps, der bruger én database, og mange brugere, der bruger forskellige rapportværktøjer (ikke kun apps) til at få adgang til data, standarder, normalisering og krav til åben arkitektur er vigtige.

På trods af de mennesker, der forsøger at ændre definitionen af ​​"normalisering" osv. for at passe til deres evigt skiftende formål, har Normalisering (videnskaben) ikke ændret sig.

• hvis du har dataværdier såsom {Open; Closed; etc } gentaget i datatabeller, dvs. dataduplikering , en simpel normaliseringsfejl:Hvis du ændrer disse værdier, skal du muligvis opdatere millioner af rækker, hvilket er meget begrænset design.

  • Sådanne værdier bør normaliseres til en reference- eller opslagstabel med en kort CHAR(2) PK:

    O  Open
    C  Closed
    U  [NotKnown]
    

  • dataværdierne {Open;Closed;etc } duplikeres ikke længere i millioner af rækker. Det sparer også plads.

  • det andet punkt er let at ændre, hvis Closed blev ændret til Expired , igen, en række skal ændres, og det afspejles i hele databasen; hvorimod millioner af rækker skal ændres i de ikke-normaliserede filer.

  • Tilføjelse af nye dataværdier , for eksempel. (H,HalfOpen ) er så blot et spørgsmål om at indsætte en række.

• i Åben arkitektur vilkår, er opslagstabellen en almindelig tabel. Det findes i det [SQL-kompatible] katalog; så længe FOREIGN KEY relation er blevet defineret, kan rapportværktøjet også finde det.

• ENUM er en ikke-SQL, brug den ikke. I SQL er "enum" en opslagstabel.

• Det næste punkt vedrører nøglens meningsfuldhed.

  • Hvis nøglen er meningsløs for brugeren, fint, brug en {INT;BIGINT;GUID;etc } eller hvad der er passende; numer dem ikke trinvist; tillad "huller".
  • Men hvis nøglen er meningsfuld for brugeren, så brug ikke et meningsløst tal, brug en meningsfuld relationsnøgle.

• Nu vil nogle mennesker komme ind på tangenter med hensyn til varigheden af ​​PK'er. Det er et særskilt punkt. Ja, selvfølgelig, brug altid en stabil værdi for en PK (ikke "uforanderlig", fordi sådan noget ikke eksisterer, og en systemgenereret nøgle giver ikke række unikke).

  • {M,F } vil sandsynligvis ikke ændre sig

  • hvis du har brugt {0,1,2,4,6 }, så lad være med at ændre det, hvorfor vil du det. Disse værdier skulle være meningsløse, husk, kun en meningsfuld nøgle skal ændres.

  • hvis du bruger meningsfulde nøgler, så brug korte alfabetiske koder, som udviklere let kan forstå (og udlede den lange beskrivelse af). Du vil kun sætte pris på dette, når du koder SELECT og indse, at du ikke behøver at JOIN hver opslagstabel. Superbrugere sætter også pris på det.

• Da PK'er er stabile, især i opslagstabeller, kan du sikkert kode:

  WHERE status_code = 'O' -- Open

  Det behøver du ikke JOIN opslagstabellen og få fat i dataværdi Open , som udvikler formodes du at vide, hvad opslags-PK'erne betyder.

Til sidst, hvis databasen var stor og understøttede BI- eller DSS- eller OLAP-funktioner ud over OLTP (som korrekt normaliserede databaser kan), så er opslagstabellen faktisk en dimension eller vektor, i Dimension-Fact analyser. Hvis det ikke var der, så skulle det tilføjes for at opfylde kravene til den pågældende software, før sådanne analyser kan monteres.

• Hvis du gør det med din database fra starten, behøver du ikke opgradere den (og koden) senere.

Dit eksempel

SQL er et sprog på lavt niveau, så det er besværligt, især når det kommer til JOINs . Det er det, vi har, så vi skal bare acceptere hæftelsen og håndtere den. Din eksempelkode er fin. Men enklere formularer kan gøre det samme.

Et rapportværktøj ville generere:

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

Et andet eksempel

For banksystemer, hvor vi bruger korte koder, der er meningsfulde (da de er meningsfulde, ændrer vi dem ikke med årstiderne, vi tilføjer dem bare), givet en opslagstabel som (omhyggeligt udvalgt, svarende til ISO landekoder) :

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

Kode som denne er almindelig:

WHERE InstrumentTypeCode LIKE "Eq%"

Og brugerne af GUI'en ville vælge værdien fra en rullemenu, der viser
{Equity/Common Share;Over The Counter },
ikke {Eq;OTC;OF }, ikke {M;F;U }.
Uden en opslagstabel kan du ikke gøre det, hverken i apps eller i rapportværktøjet.