Das Problem hier ist Subtyping . Es gibt drei grundlegende Ansätze zum Umgang mit Subtypen.
- Fügen Sie jeden Datensatztyp in eine vollständig separate Tabelle ein;
- Schreiben Sie einen Datensatz in eine übergeordnete Tabelle und dann einen Datensatz in eine Untertyptabelle; und
- Legen Sie alle Datensätze in eine Tabelle, die nullfähige Spalten für die "optionalen" Daten hat (dh Dinge, die für diesen Typ nicht gelten).
Jede Strategie hat ihre Vorzüge.
Beispielsweise ist (3) besonders anwendbar, wenn es wenig bis gar keinen Unterschied zwischen verschiedenen Subtypen gibt. Haben in Ihrem Fall verschiedene Protokolldatensätze zusätzliche Spalten, wenn sie einem bestimmten Typ angehören? Wenn dies nicht der Fall ist oder es nur wenige Fälle gibt, in denen dies der Fall ist, ist es absolut sinnvoll, sie alle in einer Tabelle zusammenzufassen.
(2) wird häufig für einen Partytisch verwendet. Dies ist ein gängiges Modell in CRMs, das ein übergeordnetes Party-Objekt beinhaltet, das Untertypen für Person und Organisation hat (Organisation kann auch Untertypen wie Unternehmen, Vereinigung usw. haben). Person und Organisation haben unterschiedliche Eigenschaften (z. B. Anrede, Vornamen, Geburtsdatum usw. für Person), daher ist es sinnvoll, diese aufzuteilen, anstatt nullfähige Spalten zu verwenden.
(2) ist möglicherweise platzsparender (obwohl der Overhead von NULL-Spalten in modernen DBMS sehr gering ist). Das größere Problem ist, dass (2) für Entwickler verwirrender sein könnte. Sie werden eine Situation bekommen, in der jemand irgendwo ein zusätzliches Feld speichern muss und es in eine Spalte hauen wird, die für diesen Typ leer ist, einfach weil es einfacher ist, dies zu tun, als die Genehmigung für die DBAs zu erhalten, eine Spalte hinzuzufügen (nein, ich mache keine Witze ).
(1) ist meiner Erfahrung nach wahrscheinlich das am wenigsten häufig verwendete Schema der 3.
Schließlich muss die Skalierbarkeit berücksichtigt werden und ist wahrscheinlich der beste Fall für (1). An bestimmten Punkten skalieren JOINs nicht effektiv und Sie müssen eine Art Partitionierungsschema verwenden, um Ihre Tabellengrößen zu reduzieren. (1) ist eine Methode, dies zu tun (aber eine grobe Methode).
Ich würde mir da aber nicht allzu viele Gedanken machen. Normalerweise müssen Sie Hunderte von Millionen oder Milliarden von Datensätzen erreichen, bevor dies zu einem Problem wird (es sei denn, Ihre Datensätze sind wirklich sehr, sehr groß, in diesem Fall wird es früher passieren).
