Datenbank-Performance: Verwendung einer Entity / Tabelle mit der max. mögliche Eigenschaften oder auf verschiedene Entitäten / Tabellen aufgeteilt?

Ich muss einige Datenbanktabellen entwerfen, bin mir aber nicht sicher über die Auswirkungen auf die Leistung. In meinem Fall geht es mehr um die Leseleistung als um das Speichern der Daten.

Die Situation

Mit Hilfe der Mustererkennung finde ich heraus, wie viele Werte eines bestimmten Objekts in meiner postgresql-Datenbank gespeichert werden müssen. Amount other sagen wir feste Eigenschaften der einzige Unterschied ist, wenn 1, 2 oder 3 Werte des gleichen Typs gespeichert werden müssen.

Gegenwärtig gibt es 3 Entitäten / Tabellen, die sich nur dadurch unterscheiden, dass sie 1, 2 oder 3 nicht nullbare Eigenschaften desselben Typs haben.

Zum Beispiel:

Ich erwarte mehrere Millionen Datensätze in der Produktion und ich denke, was könnte die Leistung Auswirkungen dieser Variante und was Alternativen sein könnten.

Alternativen

Andere Optionen, die mir in den Sinn kommen:

• Verwenden Sie nur eine Entitätsklasse oder -tabelle mit drei Optionen (optionTwo und optionThree sind dann nullfähig). Wenn man von Millionen von erwarteten Aufzeichnungen spricht plus caching im frage mich selbst ist es nicht eine Art "Verschwendung", Millionen von Null-Werte in mindestens zwei (Caching) Schichten (Datenbank selbst und Ruhezustand) zu speichern. In einer anderen Antwort, die ich gestern gelesen habe, speichern einen Nullwert in Postgresql brauchen nur 1 Bit, was ich denke, ist nicht so viel, wenn wir über mehrere Millionen von Datensätzen sprechen, die einige Nullable-Eigenschaften enthalten können ( link ).
• Erstellen Sie eine andere Entität / Tabelle und verwenden Sie stattdessen eine Auflistung (Liste oder Menge)

Zum Beispiel:

• Wenn diese Beziehung verwendet werden soll: Was würde beim Erstellen neuer Datensätze eine bessere Leistung bringen: Erstelle für jeden neuen EntityTest neue EntityOptions oder mache einen Nachschlagen und Referenz auf eine vorhandene EntityOption, falls vorhanden? Was ist mit der Leseleistung beim späteren Abrufen und den Joins, die dann benötigt werden? Im Vergleich zu der Variante mit einer einfachen Entity mit drei Optionen kann ich mir vorstellen, dass sie etwas langsamer sein könnte ...

Da ich im Datenbankdesign nicht so stark bin und mit Hibernate arbeite, bin ich an den Vor- und Nachteilen dieser Ansätze interessiert und wenn es noch mehr Alternativen gibt. Ich möchte sogar die Frage stellen, ob postgresql die richtige Wahl dafür ist oder ob ich darüber nachdenken sollte, eine andere (freie) Datenbank zu verwenden.

Danke!