✔ MySQL: 1 Tabelle oder 1000 Tabellen?

S

Stefan_B1

Grünschnabel
Hallo Ihrs,

nach einiger Excel-Spielerei während meines studentischen Praktikums (nun über 4 Monate) wird es Zeit aus der "Spielerei" etwas ernstes zu machen.

Vorgeschichte:
Ich habe eine Excel-VBA Anwendung geschrieben, welche Maschinenfehler-History Files 'einliest' (txt, csv) und diese etwas anschaulicher darstellt (Sortierfunktionen, automatische Diagramme etc)

Dieses "Programm" benötigt noch viele Vorgaben und man muss immer wieder die Files neu einlesen... zudem müsste jeder Anwender die Files sowie auch das Programm auf seinen Rechner ziehen und und und...

Also da soll eine andere Lösung her....
eine Datenbankanwendung auf einem Server (im Firmeninternen Netzwerk)


Nun aber zur eigentlichen Frage nach dieser kurzen Einführung:

In Excel hatte ich die einzeln vorkommenden Fehlerstrings (Beispiel: "Not Aus Maschine 4" & Zeitstempel) nun direkt nach "Fehlerstrings" sortiert gehabt.
Also in der Spalte:
Fehlerstring1 | Fehlerstring 2 | ...
Zeit 1-1 | Zeit 1-2 | ...
Zeit 2-1 | Zeit 2-2 | ...
Zeit 3-1 | Zeit 3-1 | ...
Zeit 4-1 | ... | ...
... | ... | ...

Nun, in einer Datenbank bieten sich nun 2 Möglichkeiten an......

EINE einzige Tabelle mit jeweils ca 10 Spalten (mit mehr Infos zum Fehler unter anderem auch Zeitstempel und String(ID) )

ODER FÜR JEDEN EINZELNEN Fehlerstring eine eigene Tabelle!
Das heisst also .... tausende Tabellen unter Umständen ....

Programmieraufwand wäre beides wohl ähnlich...
... interessant ist aber wie ich nun schneller auf die Daten Zugreifen kann.... und ob .. sry, das blieb hier im Text unerwähnt..
... ich benutze MySQL ..
also ob MySQL mit 1000+ Tabellen umgehen kann.
Die Tabellennamen wären schlicht in einer einzelnen Datenbank erfasst, also als "Variablen" gespeichert. So ermögliche ich mir den programmtechnischen Zugriff (in der Überlegung)

Also:
eine Tabelle mit pro Tag 10000 neuen Datensätzen, oder 1000 Tabellen mit pro Tag "durchschnittlich" 10 neuen Datensätzen pro Tabelle

Wichtig ist vor allem die "zeitliche Abfrage", also "Select Where zeit < dies und > jenes AND string = diesunddas AND ..."

Abgefragt wird relativ selten... geschrieben bei weitem öfter(!) (beim Schaffen einer automatischen Einlesung fast jede Sekunde) .. Updated nie ... höchstens manuell & administrativ gelöscht oder eine Sicherung erstellt

yo, Eine oder Tausende Tabellen?

wäre auch sehr froh über eine kurze Warum-Erklärung als DB-Neuling und MySQL-Neuling
 
Eine Datenbank und zwei Tabellen.


Ich kenne Deinen Fall nicht genau. Deshalb schildere ich es an einem Beispiel. Es sollen Adresen gespeichert werden. Das kann man in einer Tabelle tun:

### Adresse ###
ID_A | Name | Vorname | Strasse | PLZ | Ort | Telefon

Irgendwann später stellt man fest, dass eine Person MEHRE Telefonnummer haben kann. Dumm wäre, mehre Telefonnummern in das EINE Feld Telefon zu quatschen. Genauso unprofessionell wäre es ganz viele Telefonnummerfelder anzulegen:

### Adresse ###
ID_A | Name | Vorname | Strasse | PLZ | Ort | Telefon 1 | Telefon 2 | ... | Telefon 50

Deshalb zwei Tabellen.

### Adresse ###
ID_A | Name | Vorname | Strasse | PLZ | Ort
### Telefon ####
ID_T | Telefonnummer | Verweis auf ID_A

Wieder etwas später stellst Du fest - Mist! Manche Leute haben mehre Wohnort. Also wieder alles neu programmieren, Datenmodel anpasssen etc. Du baust auch hierfür eine Tabelle.

### Person ###
ID_P | Name | Vorname
### Adresse ###
ID_A | Strasse | PLZ | Ort
### Telefon ####
ID_T | Telefonnummer | Verweis auf ID_A


Wenn man es richig machen will, löst man sich mal von der spezifischen Aufgabe und denkt mal ganz abstrakt über die Entiytäten (Abbildung der Wirklichkeit) nach und normalisiert. Dann kann einen auch in zwei Jahren es nicht schrecken, wenn plötzlich die Vorderung kommt auch mehre Vornamen und Ehefrauen zu verwalten.

Christian
 
Danke Chris für die Antwort.
Schöne Basics die mich freut zu lesen, aber mein Fall ist damit leider nicht erklärt.

Also ich verdeutliche nochmal anhand von "Beispielen"

Möglichkeit 1: EINE Tabelle

Tabellenname: z.B. History_All
ID_Eintrag | ID_String | Parameter | Zeitstempel | ... weitere Werte unwichtig

Erklärung: ID_Eintrag 'Start bis Ende' wird in einer anderen Tabelle gespeichert um einen Verweis auf eine Datei zu bekommen um diese Range 'Start bis Ende' eventuell später zu löschen
ID_String verweist auf den spezifischen 'Stringwert' und einige andere Daten zur bestimmten Meldung, jedes ID_String hat einige Daten wie "aus welchem Teil der anlage kam die Meldung" etc
Parameter kann verschiedene Werte annehmen, ist aber optional
Zeitstempel ist wohl das wichtigste für den Abruf von Daten

Diese, einzelne Tabelle, wird wohl mit 10000 Einträgen pro Tag gefüttert


Möglichkeit 2: Viele Programmerzeugte Tabellen
Orientiert an Möglichkeit 2, wird nun für JEDEN 'ID_String' eine eigene Tabelle angelegt. ID_String fällt also weg oben und findet sich irgendwie "im Tabellennamen" wieder.
Sähe dann so aus:

Tabellennamen: Messages_($ID_String)
$ID_String = 1 , 2 , 3 , ... , n
ID_Eintrag | Parameter | Zeitstempel | ... weitere Werte unwichtig

Erklärungen zu den Spalten wie oben. ID_String fällt weg und taucht im Tabellennamen wieder auf um den Zugriff zu identifizieren.

__________________________

Fazit: Die Entscheidung fällt schwer, vor allem das "schreiben" wird dadurch komplizierter, weil ja sortiert werden muss. Das Lesen wird für den speziellen Fall einen bestimmten "ID_String" zu betrachten sicher besser....
... natürlich mit dem Nachteil wenn ich alle "ID_Strings" aus einem bestimmten Zeitrahmen holen möchte.

__________________________

Nochmal zurück zur Fragestellung:
Angenommen es soll sich nun wirklich auf den Zugriff auf einen bestimmten "ID_String" konzentriert werden als meist genutzte Abfrage.

Hat es eigentlich einen Sinn nun soviel Tabellen zu erstellen (was ja auch extrem unübersichtlich wird) oder wäre selbst bei Millionen Datensätzen in Tabelle "History_All" ein schneller Zugriff auf "Select ... Where ID_String = $Wert" möglich? Definition Schnell: wenige Sekunden, bestenfalls natürlich < 1 Sekunde.

Leider fehlt mir die Erfahrung dazu nur irgendeine Vorstellung zu haben.
 
Ich würde die Variante 1 bevorzugen. Das andere gibt ein gezettel und wird nicht lustig, wenn du jemals etwas an der Taeblle ändern musst.

Was du machen könntest, währe eine normalisierung auf ID_STRING. Sprich, den Text in eine Tabelle auslagern und mittels einer ID verlinken. Wenn du noch gute Indexe setzt, sollte das ganze auch halbwegs passabel in der Performance sein (kommt natürlich auf die DB an)
 
@yaslaw
Yo ID_String ist ja ausgelagert ;) Wäre vermutlich Worst-Case Millionen von 50 Zeichen Strings zu sichern, von den es aber nur 1000 Variantionen gäbe. <=> also ab damit als Link und ID

Meine Tendenz geht in "eine Tabelle", schon wegen des "Programmieraufwandes" und der Anfälligkeit bei Ausführungsfehlern.

Kann man sagen, dass generell variabel generierte Tabellen problematisch sind?

Wäre interessant ob es noch Gegen-Meinungen gibt.

Wie schnell der Zugriff ist, werde ich wohl erst erfahren wenn das ganze steht... da bin ich mal richtig neugierig... das hängt vermutlich nämlich direkt mit der Nutzung in der Praxis zusammen :(
 
Zuletzt bearbeitet:
Hi,

grundsätzlich kann man jede Relationale DB in EINE Tabelle bringen. Ich würde es nicht tun.
Das was Du schreibst, kenne ich aus einem frühren Projekt. Hier war die Anforderung für eine automatisierte Fertigungsanlage Produktionsparameter und Qualitätskennzahlen zu speichern.
Beispiel: Galvanik mit mehren Becken. Gespeichert wurden Temperatur, % Werte der enthaltenen Flüssigkeiten, Tauchzeit, Stromspannung etc.
Es wurde pro Aggregat bis zu 10 Werten pro Sekunde gespeichert. War eine Menge an Daten (200 Laufwagen, 2 Galvanikanlagen, Öffen, Spitzanlage, Pulverbeschichtung etc.)
Wir haben sehr viel experimentiert und sind dann zu einer Lösung gekommen:

Sehr stark normalisiert:

### Log ###
ID | Zeitstempel | Wert | Typ | Bezeichnung | Auslössendes Aggregat | Status | Mitarbeiter

In extra Tabellen waren dann:
Typ (Strom, Geschwindigkeit, Zeit also alles was man sich so vorstellen konnte)
Bezeichnung (Ventil XY, Wegkontrollpunkt N, Messpunk 0815)
Auslössendes Aggregat (Pulverkabine, Brennoffen, Galvanik 1)
Status (Normal, Warnung, Kritisch)
Mitarbeiter (Kein Mitarbeiter = NULL | Verantwortlicher Mitarbeiter ID)
gelistet.

Wenn man dann einen Status zu einem Zeitpunkt vom Ofen haben wollte, bekam man halt eine Ladung von einigen Tausend Werten zurück. Vorteil war die Flexiblität. Wärend der Entwicklungszeit wurde nicht nur einmal ein Messfühler hinzu oder weggebaut. Nach zwei Jahren wünschte der Kunde eine weitere Fertigungsschiene - kein Problem.

Die Antwortzeiten der Abfragen im Logbuch waren für einzelne Werte kaum messbar. Die Anlage läuft auch nach 8 Jahren noch 24h pro Tag. Das Datenvolumen darf als anspruchsvoll gelten.

Vorteile:
+ Flexibiliät
+ Weniger Speicherplatz
+ sehr kleine Datensätze bei Schreibvorgängen

Nachteile:
- Komplexere Abfragen

Chris
 
Zuletzt bearbeitet:
hui,
dieses Beispiel mit dem wichtigen Inhalt, dass die Antwortzeiten von Abfragen vernachlässigbar sind, beantwortet meine Frage zur Genüge.

Danke dir!

Tatsächlich ist dein Beispiel sehr ähnlich zu meinen Anforderungen & praktisch arbeite ich das genauso aus wie du beschrieben hast (also Verweise auf Anlagen, Module der Anlagen, etc)

Das bringt doch mal Licht ins Dunkel für jemanden wie mich, der auf dem Gebiet DB-Anwendungen recht neu ist.

Als Hinweis zu meiner Arbeit:
Als Praktikant ist meine Aufgabe vor allem den Leuten hier zu zeigen "was möglich ist"... und dies "Ansatzweise" praktisch umzusetzen für ein Projekt (zeigen dass es sich loht).
Nicht ganz uneigennützig meinerseits könnte das Unternehmen bei diesem Projekt unter Umständen auch wieder auf mich zurückkommen nach meinem Praktikum ;) ... was ja auch schon der Fall ist, dass ich als Werkstudent bald hier bin und weiterbastle an der Datensicherung & vor allem Analyse (alles möglichst automatisiert), was hier bisher etwas vernachlässigt wurde bei einigen potentiell sehr aufschlussreichen Daten.
... Vor allem ein Gewinn für meine Ausbildung, mal etwas abseits meines technische Physik - Studiums.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück