Detta är en klassisk OO-design till relationstabellernas impedansfel. Tabelldesignen du har beskrivit är känd som "tabell per underklass". De tre vanligaste designerna är alla kompromisser jämfört med hur dina objekt faktiskt ser ut i din app:
- Tabell per betongklass
- Tabell per hierarki
- Tabell per underklass
Designen du inte gillar - "där tabeller har 100 kolumner och de flesta av värdena är NULL" - är 2. en tabell för att lagra hela specialiseringshierarkin. Detta är det minst flexibla av alla möjliga skäl, inklusive - om din app kräver en ny underklass måste du lägga till kolumner. Designen du beskriver tillgodoser förändring mycket bättre eftersom du kan lägga till utöka den genom att lägga till en ny underklasstabell som beskrivs av ett värde i product_type.
Det återstående alternativet - 1. Tabell per betongklass - är vanligtvis oönskat på grund av dubbelarbetet med att implementera alla vanliga fält i varje specialiseringstabell. Även om fördelarna är att du inte behöver utföra några joins och underklasstabellerna kan till och med finnas på olika db-instanser i ett mycket stort system.
Designen du beskrev är helt genomförbar. Variationen nedan är hur det skulle kunna se ut om du använde ett ORM-verktyg för att utföra dina CRUD-operationer. Lägg märke till hur ID:t i varje underklasstabell ÄR FK-värdet till den överordnade tabellen i hierarkin. En bra ORM kommer automatiskt att hantera den korrekta underklasstabellen CRUD baserat enbart på värdet av diskriminatorvärdena i product.id och product.product_type_id. Oavsett om du planerar att använda en ORM eller inte, titta på hibernates förenade underklassdokumentation, om så bara för att se designbesluten de fattade.
product
=======
id INT
product_name VARCHAR
product_type_id INT -> Foreign key to product_type.product_type_id
valid_since DATETIME
valid_to DATETIME
magazine
========
id INT -> Foreign key to product.product_id
title VARCHAR
..
web_site
========
id INT -> Foreign key to product.product_id INT
name VARCHAR
..