Jede Datenbank verfügt im Großen und Ganzen über zwei Arten von Tabellen – Dimensionen und Fakten:

1. Abmessungen sind die Konfigurationstabellen. Diese Tabellen werden nicht häufig geändert und stellen in der Regel einen einzelnen aktuellen Snapshot-Wert dar (möglicherweise mit einigen Verlaufsänderungen – siehe unten). Die häufigsten Vorgänge sind Bearbeitungen an der Tabelle. Man kann sich diese auch als Config oder Masters vorstellen.
2. Fakten sind Tabellen, die mit der Zeit nahezu linear zunehmen. In der Regel werden diese Entitäten im Laufe der Zeit regelmäßig generiert. Aktualisierungen der generierten Fakten sind nicht häufig und beziehen sich für mehr Kontext normalerweise auf Dimensionen.

Beim Entwerfen eines Datenbankschemas helfen einige der folgenden Richtlinien dabei, es richtig zu machen.

Zuerst normal

Unabhängig davon, ob es sich bei der Datenbank um SQL oder NoSQL handelt, ist es sinnvoll, die Entitäten/Objekte und damit die Tabellen einmal aus einer normalisierten Schemaperspektive zu betrachten. Das normalisierte Schema sorgt für Klarheit über die Entitäten, Beziehungen und Felder. Die Denormalisierung oder Konvertierung zu NoSQL kann unkompliziert und ein bewusstes Design sein.

Spiegeln Sie reale Entitäten

Auch wenn die Anwendungsfälle/Berichte unklar sind, sollten die Schema-Entitäten den realen Anwendungsfall widerspiegeln. Ein solches Schema ist normalerweise robust.

In den folgenden Fällen werden im Allgemeinen verschiedene Entitäten und damit Tabellen identifiziert und erstellt:

1. Logisch getrennte Einheiten, die unabhängig und möglicherweise ohne Verbindung zueinander existieren können – z. B. Datensatz und Station
2. Haben Sie Viele-zu-Viele-Beziehungen oder Eins-zu-Viele-Beziehungen untereinander – z. B. für ein E-Commerce-Unternehmen, Bestellungen und Kunden.

Wenn ein Feld in Abfragen, bei der Suche oder beim Sortieren verwendet wird, fügen Sie standardmäßig Indizes dafür hinzu. Für diese Felder sollten standardmäßig einfache Indizes aktiviert sein, da sie den größtmöglichen Nutzen haben. Es sollte eine bewusste Entscheidung sein, keinen Index hinzuzufügen, und nicht der Standardzustand.

Verwenden Sie die richtigen Feldtypen

1. Aufzählung vs. String-Typen für Felder mit einem festen Satz an Optionswerten: Aufzählungen werden als Byte implementiert, beanspruchen daher weniger Platz (z. B. 1–4 Byte langes Byte/Long/Int vs. 128-Byte-String), sind bei Indizes schneller/schneller sucht. Bei großen Tischen addieren sich Platz- und Leistungsbedarf. Verwenden Sie standardmäßig Aufzählungen.
2. Typ des Primärschlüssels (ID): Aus Leistungs- und Speichergründen ist es immer ratsam, einen Schlüssel mit fester Größe zu verwenden, z. B. ganze Zahlen oder UUIDs.
3. Gemeinsame Tabellenfelder: Einige Felder werden in allen ORM-Entitäten vorgeschlagen, die sich ändern können – z. B. „created_at“, „update_at“, „created_by“, „update_by“. Darüber hinaus wird für Entitäten, die häufig über Fremdschlüsselverknüpfungen verfügen und selten gelöscht werden, die Verwendung von Soft-Deletes vorgeschlagen.

Drishtis Abfrage kann komplex sein und mehrere Verknüpfungen umfassen. Datenbanken sind für In-Memory-Joins und -Berechnungen optimiert. Führen Sie diese Verknüpfungen oder Berechnungen nach Möglichkeit in der Datenbank aus – entweder durch Ergänzungen zur ORM-Ebene, durch geeignete Abfragen oder durch eine Schema-Neugestaltung. Als Faustregel gilt, dass man sich große Ergebnis-Joins im Anwendungscode nur dann ansehen sollte, wenn die Datenbank dies im Speicher nicht tun kann – z. B. bei datenbankübergreifenden Joins.

Wann sollten Verlaufstabellen hinzugefügt werden?

Jedes transaktionsbasierte System benötigt eine grundlegende Protokollierung aller Änderungen für die Schlüsselentitäten. Dies gilt insbesondere für Dimensionstabellen, da diese über die APIs konfiguriert/geändert werden.

Es gibt zwei Möglichkeiten, sie aufrechtzuerhalten:

1. Behalten Sie eine generische Abstraktion für Attributänderungen bei, wobei jede Zeile in diesem Änderungsverlauf auf den Entitätstyp, das Attribut, die Entitäts-ID, den alten und den neuen Wert verweist. Vorteil: Es ist keine neue Tabelle pro Entität erforderlich.
2. Führen Sie für jede Wertänderung eine entitätsbezogene Verlaufstabelle. Vorteil: Erfassen Sie mehrere Feldänderungen als atomare Transaktionen und zeigen Sie sie dem Kunden als solche an. Somit bleibt das Konzept einer Transaktion, wie sie vom Benutzer am Frontend oder auf andere Weise durchgeführt wird, erhalten.