Dies ist ein klassisches OO-Design für Impedanzfehlanpassungen relationaler Tabellen. Das von Ihnen beschriebene Tabellendesign ist als "Tabelle pro Unterklasse" bekannt. Die drei gängigsten Designs sind allesamt Kompromisse im Vergleich dazu, wie Ihre Objekte in Ihrer App tatsächlich aussehen:
- Tabelle pro Betonklasse
- Tabelle pro Hierarchie
- Tabelle pro Unterklasse
Das Design, das Sie nicht mögen - "wo Tabellen 100 Spalten haben und die meisten Werte NULL sind" - ist 2. eine Tabelle zum Speichern der gesamten Spezialisierungshierarchie. Dies ist aus verschiedenen Gründen am wenigsten flexibel, einschließlich:Wenn Ihre App eine neue Unterklasse erfordert, müssen Sie Spalten hinzufügen. Das von Ihnen beschriebene Design passt sich Änderungen viel besser an, da Sie es erweitern können, indem Sie eine neue Unterklassentabelle hinzufügen, die durch einen Wert in product_type beschrieben wird.
Die verbleibende Option - 1. Tabelle pro konkreter Klasse - ist normalerweise unerwünscht, da die Implementierung aller gemeinsamen Felder in jeder Spezialisierungstabelle doppelt ausgeführt werden muss. Die Vorteile bestehen jedoch darin, dass Sie keine Joins durchführen müssen und die Unterklassentabellen sich sogar auf verschiedenen Datenbankinstanzen in einem sehr großen System befinden können.
Das von Ihnen beschriebene Design ist absolut realisierbar. Die folgende Variation zeigt, wie es aussehen könnte, wenn Sie ein ORM-Tool für Ihre CRUD-Operationen verwenden würden. Beachten Sie, dass die ID in jeder Unterklassentabelle der FK-Wert für die übergeordnete Tabelle in der Hierarchie ist. Ein gutes ORM verwaltet automatisch die richtige Unterklassentabelle CRUD basierend auf dem Wert der Diskriminatorwerte in product.id und product.product_type_id allein. Unabhängig davon, ob Sie ein ORM verwenden möchten oder nicht, sehen Sie sich die Dokumentation der verbundenen Unterklassen von Hibernate an, und sei es nur, um die von ihnen getroffenen Designentscheidungen zu sehen.
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
..
