Het probleem hier is subtypen . Er zijn drie basisbenaderingen om met subtypen om te gaan.
- Zet elk recordtype in een volledig aparte tabel;
- Zet een record in een bovenliggende tabel en vervolgens een record in een subtypetabel; en
- Zet alle records in één tabel, met nullable-kolommen voor de "optionele" gegevens (dwz dingen die niet van toepassing zijn op dat type).
Elke strategie heeft zijn voordelen.
(3) is bijvoorbeeld vooral van toepassing als er weinig tot geen verschil is tussen verschillende subtypes. Hebben verschillende logrecords in uw geval extra kolommen als ze van een bepaald type zijn? Als ze dat niet doen, of er zijn weinig gevallen waarin ze dat wel doen, is het volkomen logisch om ze allemaal in één tabel te zetten.
(2) wordt vaak gebruikt voor een feesttafel. Dit is een veelgebruikt model in CRM's waarbij een bovenliggend partijobject is betrokken dat subtypen heeft voor Persoon en Organisatie (Organisatie kan ook subtypen hebben zoals Bedrijf, Vereniging, enz.). Persoon en Organisatie hebben verschillende eigenschappen (bijv. aanhef, voornamen, geboortedatum, enz. voor Persoon), dus het is logisch om dit op te splitsen in plaats van nullable-kolommen te gebruiken.
(2) is potentieel meer ruimtebesparend (hoewel de overhead van NULL-kolommen in moderne DBMS's erg laag is). Het grotere probleem is dat (2) misschien meer verwarrend is voor ontwikkelaars. Je krijgt een situatie waarin iemand ergens een extra veld moet opslaan en het in een kolom zal slaan die leeg is voor dat type, simpelweg omdat het gemakkelijker is om dat te doen dan goedkeuring te krijgen voor de DBA's om een kolom toe te voegen (nee, ik maak geen grapje ).
(1) is waarschijnlijk het minst vaak gebruikte schema van de 3 in mijn ervaring.
Ten slotte moet schaalbaarheid worden overwogen en dit is waarschijnlijk het beste geval voor (1). Op een bepaald punt schalen JOIN's niet effectief en moet je een soort partitieschema gebruiken om je tabelgrootte te verkleinen. (1) is een methode om dat te doen (maar een ruwe methode).
Ik zou me daar echter niet al te veel zorgen over maken. Normaal gesproken moet u honderden miljoenen of miljarden records hebben voordat dat een probleem wordt (tenzij uw records echt heel groot zijn, in welk geval het eerder zal gebeuren).