Problemet her er underskrivning . Der er tre grundlæggende tilgange til at håndtere undertyper.
- Sæt hver posttype i en helt separat tabel;
- Sæt en post i en overordnet tabel og derefter en post i en undertypetabel; og
- Sæt alle posterne i én tabel med nullbare kolonner for de "valgfri" data (dvs. ting, der ikke gælder for den type).
Hver strategi har sine fordele.
For eksempel er (3) især anvendelig, hvis der er lille eller ingen forskel mellem forskellige undertyper. I dit tilfælde, har forskellige logposter ekstra kolonner, hvis de er af en bestemt type? Hvis de ikke gør det, eller der er få tilfælde, hvor de gør, giver det perfekt mening at lægge dem alle i én tabel.
(2) er almindeligt brugt til et festbord. Dette er en almindelig model i CRM'er, der involverer et overordnet partiobjekt, som har undertyper til person og organisation (Organisationen kan også have undertyper som firma, forening osv.). Person og organisation har forskellige egenskaber (f.eks. hilsen, fornavne, fødselsdato osv. for person), så det giver mening at dele dette op i stedet for at bruge nullable kolonner.
(2) er potentielt mere pladseffektiv (selvom overheaden af NULL-kolonner i moderne DBMS'er er meget lav). Det større problem er, at (2) kan være mere forvirrende for udviklere. Du vil få en situation, hvor nogen har brug for at gemme et ekstra felt et eller andet sted og vil smække det i en kolonne, der er tom for den type, simpelthen fordi det er nemmere at gøre det end at få godkendelse af DBA'erne til at tilføje en kolonne (nej, jeg laver ikke sjov ).
(1) er nok det mindst hyppigt anvendte skema af de 3 efter min erfaring.
Til sidst skal skalerbarhed overvejes og er sandsynligvis det bedste tilfælde for (1). På visse punkter skaleres JOINs ikke effektivt, og du bliver nødt til at bruge en slags partitioneringsskema for at skære ned på dine bordstørrelser. (1) er en metode til at gøre det (men en rå metode).
Jeg ville dog ikke bekymre mig så meget om det. Du bliver typisk nødt til at nå hundreder af millioner eller milliarder af poster, før det bliver et problem (medmindre dine poster er virkelig store, i hvilket tilfælde det vil ske hurtigere).