Ich entwerfe eine Datenbank mit Statistiken über den Betrieb mechanischer Maschinen. Jeder Datenstapel enthält Hunderte von Statistiken. Daher versuche ich zu entscheiden, ob eine einzelne Tabelle mit Hunderten von Spalten erstellt oder in mehrere Tabellen aufgeteilt wird, die jeweils zugehörige Statistiken enthalten. Zum Beispiel könnte ich eine Tabelle mit den Statistiken zu Fehlfunktionen haben, eine weitere Tabelle mit Statistiken zu Staus usw.
Die Verwendung mehrerer Tabellen würde das System insgesamt komplexer machen, obwohl es konzeptionell einfacher für mich ist, mit mehreren kleineren Tabellen als einem großen zu arbeiten.
Wäre es für die Aufspaltung von Leistung ein Vorteil? Es scheint, als wäre die Abfrage einer Tabelle mit ein paar Dutzend Spalten schneller als die Abfrage einer Tabelle mit Hunderten von Spalten.
Hat jemand Erfahrung mit so etwas? Ich benutze Oracle für dieses Projekt, obwohl ich wahrscheinlich in Zukunft auf solche Datenbanken stoße, sodass die Antworten für jede Datenbank geschätzt werden.
Ich denke, wir müssen mehr über Ihr Design wissen, um es richtig beantworten zu können. Zum Beispiel bin ich neugierig, dass es viele Spalten geben könnte, die sich auf Fehlfunktionen beziehen, viele (von verschiedenen) in Bezug auf Staus usw. (Ist ein Stau nicht nur eine Art Fehlfunktion?)
Ist Ihr Entwurf normalisiert? Vermutlich haben Sie keine Spalten wie "jam1", "jam2", etc.?!
Unter der Annahme, dass das Design gut und normalisiert ist, ist die Entscheidung, ob eine breite oder viele engere Tabellen verwendet werden sollen, eine Abwägung zwischen verschiedenen Faktoren:
Wie auch immer Sie vorgehen, Sie können Ansichten verwenden, um die alternative Struktur für die Bequemlichkeit des Entwicklers zu präsentieren:
Aus Ihren Kommentaren weiß ich jetzt, dass Sie an 40 verschiedenen Stellen auf der Maschine Staus zählen, und andere Arten von Stats sind ähnlich. Dies deutet auf das folgende Tabellendesign hin:
%Vor%Wenn jemand im Folgenden kommentiert, können Sie damit Statistiken leichter zusammenfassen - innerhalb oder über Stat-Typen hinweg. Es kann auch einfach erweitert werden, wenn eine neue Statistik zu einem Stat-Typ hinzugefügt werden muss.
Wenn ich Hunderte von Spalten in einer Tabelle sehe, tendiere ich dazu zu vermuten, dass das Datenschema nicht richtig normalisiert wurde. Sind die Hunderte von Spalten wirklich einzigartig oder sind sie Gruppen von ähnlichen Dingen, die in kleinere Tabellen normalisiert werden können?
Wenn Sie die Anzahl der Spalten reduzieren können, können Sie die Gesamtmenge der Daten reduzieren und somit die Leistung auf mehreren Ebenen verbessern. Wenn Sie beispielsweise einen Datensatz haben, der 1000 Byte Daten enthält und Sie für jeden Datensatz 1 Byte ändern möchten, riskieren Sie unnötigerweise 999 Byte zu holen und zu speichern. Dies beeinträchtigt die Leistung.
Meinst du 100 Arten von Statistiken?
Einige medizinische Datenbanken haben versucht, ein Schema oder eine Redewendung, die "Entity-Attribut-Wert" oder "EAV" genannt wird (Sie können diese Begriffe googlen): Die Begründung ist, dass es unzählige verschiedene Arten von Fakten über einen Patienten gibt, die oder möglicherweise nicht für einen bestimmten Patienten erfasst worden, und EAV ist eine bessere Möglichkeit, dies zu speichern als unzählige verschiedene Spalten in einer Tabelle zu haben.
Beachten Sie jedoch, dass EAV umstritten ist: Manche sagen, es ist ein "Code-Geruch" und typischer Newbie-Fehler; Andere sagen, dass es gelegentlich nützlich ist (oder selten), aber es hängt von der Angabe (und Angabe) einer guten Unterstützung für Metadaten ab.
Ich mag Tabellen mit zu vielen Spalten nicht. Eine Option, die Sie in Betracht ziehen könnten, ist, die Statistiken als Zeilen in einer Statistik-Tabelle zu speichern:
%Vor%Dann fügen Sie einfach eine neue Zeile mit jedem Status hinzu, den Sie verfolgen. Das ist aus DB-Sicht viel sauberer, aber es macht die Daten für Berichte schwieriger.
In dieser Situation würde ich ein paar Tabellen erstellen. Einer wäre der Maschinentisch. Eine wäre eine Nachschlagetabelle. Schließlich eine Verbindungstabelle zwischen den beiden, die auch Informationen enthält, die sich auf den Status beziehen. Die Wartung wird einfacher und das Schreiben von verrückten Berichten wird einfacher. Auch das Hinzufügen neuer Statustypen wird einfacher.
%Vor%Dann kannst du Sachen machen wie: Wählen Sie count (distinct machine_id) aus machine_history, wobei status_flag_id = 23 und Information & lt; 5;
Das Informationsfeld in der Tabelle machine_history muss nur Zahlen oder Zeichen enthalten. Wenn dies der Fall ist, würde ich zwei Informationsfelder erstellen, damit Sie die Leistung nicht behindern.
Ich gehe auch davon aus, dass es eine Programmierkomponente gibt, mit der Sie einige Methoden zum einfachen Arbeiten mit diesen Daten erstellen können.
Tags und Links database-design