Hoe belangrijk zijn opzoektabellen?

Het antwoord hangt een beetje af als je beperkt bent tot freeware zoals PostGreSQL (niet volledig SQL-compatibel), of als je denkt aan SQL (dwz SQL-compatibel) en grote databases.

In SQL-compatibel, Open architectuur databases, waar veel apps één database gebruiken, en veel gebruikers die verschillende rapportagetools gebruiken (niet alleen de apps) om toegang te krijgen tot de gegevens, standaarden, normalisatie en open architectuurvereisten zijn belangrijk.

Ondanks de mensen die proberen de definitie van "normalisatie", enz. aan te passen aan hun steeds veranderende doel, is normalisatie (de wetenschap) niet veranderd.

• als u gegevenswaarden . heeft zoals {Open; Closed; etc } herhaald in datatabellen, dat is gegevensduplicatie , een eenvoudige normalisatiefout:als u die waarden wijzigt, moet u mogelijk miljoenen rijen bijwerken, wat een zeer beperkt ontwerp is.

  • Dergelijke waarden moeten worden genormaliseerd in een referentie- of opzoektabel, met een korte CHAR(2) PK:

    O  Open
    C  Closed
    U  [NotKnown]
    

  • De gegevenswaarden {Open;Closed;etc } worden niet langer gedupliceerd in de miljoenen rijen. Het bespaart ook ruimte.

  • het tweede punt is het gemak van verandering, indien Closed zijn gewijzigd in Expired , nogmaals, er moet één rij worden gewijzigd, en dat wordt weerspiegeld in de hele database; terwijl in de niet-genormaliseerde bestanden miljoenen rijen moeten worden gewijzigd.

  • Nieuwe gegevenswaarden toevoegen , bijv. (H,HalfOpen ) is dan gewoon een kwestie van één rij invoegen.

• in Open Architectuur termen, is de opzoektabel een gewone tabel. Het bestaat in de [SQL-compatibel] catalogus; zolang de FOREIGN KEY relatie is gedefinieerd, kan de rapportagetool dat ook vinden.

• ENUM is een Non-SQL, gebruik het dan niet. In SQL is de "enum" een opzoektabel.

• Het volgende punt heeft betrekking op de betekenis van de sleutel.

  • Als de sleutel geen betekenis heeft voor de gebruiker, prima, gebruik dan een {INT;BIGINT;GUID;etc } of wat dan ook geschikt is; nummer ze niet stapsgewijs; "gaten" toestaan.
  • Maar als de sleutel betekenisvol is voor de gebruiker, gebruik dan geen betekenisloos getal, maar een betekenisvolle relationele sleutel.

• Nu zullen sommige mensen raakvlakken krijgen met betrekking tot de duurzaamheid van PK's. Dat is een apart punt. Ja, natuurlijk, gebruik altijd een stabiele waarde voor een PK (niet "onveranderlijk", omdat zoiets niet bestaat, en een door het systeem gegenereerde sleutel biedt geen rij-uniciteit).

  • {M,F } zullen waarschijnlijk niet veranderen

  • als je {0,1,2,4,6 . hebt gebruikt }, nou verander het niet, waarom zou je dat willen. Die waarden zouden betekenisloos zijn, onthoud, alleen een betekenisvolle sleutel hoeft te worden gewijzigd.

  • als je zinvolle sleutels gebruikt, gebruik dan korte alfabetische codes die ontwikkelaars gemakkelijk kunnen begrijpen (en waaruit de lange beschrijving kan worden afgeleid). U zult dit alleen waarderen als u SELECT . codeert en realiseer je dat je niet hoeft te JOIN elke opzoektabel. Ook ervaren gebruikers waarderen het.

• Aangezien PK's stabiel zijn, met name in opzoektabellen, kunt u veilig coderen:

  WHERE status_code = 'O' -- Open

  U hoeft niet JOIN de opzoektabel en verkrijg de gegevenswaarde Open , Als ontwikkelaar wordt u verondersteld te weten wat de Lookup PK's betekenen.

Als de database groot was en BI- of DSS- of OLAP-functies naast OLTP ondersteunde (zoals correct genormaliseerde databases kunnen), dan is de opzoektabel eigenlijk een dimensie of vector, in Dimension-Fact analyseert. Als het er niet was, zou het moeten worden toegevoegd om aan de vereisten van die software te voldoen, voordat dergelijke analyses kunnen worden gemount.

• Als u dat vanaf het begin met uw database doet, hoeft u deze (en de code) later niet te upgraden.

Uw voorbeeld

SQL is een taal op laag niveau, dus het is omslachtig, vooral als het gaat om JOINs . Dat is wat we hebben, dus we moeten de last accepteren en ermee omgaan. Je voorbeeldcode is prima. Maar eenvoudigere formulieren kunnen hetzelfde doen.

Een rapporttool zou het volgende genereren:

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

Nog een voorbeeld

Voor banksystemen, waar we korte codes gebruiken die betekenisvol zijn (aangezien ze betekenisvol zijn, veranderen we ze niet met de seizoenen, we voegen ze gewoon toe), gegeven een opzoektabel zoals (zorgvuldig gekozen, vergelijkbaar met ISO-landcodes) :

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

Code zoals deze is gebruikelijk:

WHERE InstrumentTypeCode LIKE "Eq%"

En de gebruikers van de GUI zouden de waarde kiezen uit een vervolgkeuzelijst die
{Equity/Common Share;Over The Counter weergeeft. },
niet {Eq;OTC;OF }, niet {M;F;U }.
Zonder een opzoektabel kunt u dat niet doen, noch in de apps, noch in de rapporttool.