Ankündigung

Einklappen
Keine Ankündigung bisher.

Grafiken Db Machbarkeit

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Achso ok Entschuldigung, jetzt hab ichs verstanden:
    Code:
    Hersteller
    Id | Name | Code
    
    Dimension
    ID | Name | Code
    
    Resin
    ID | Name | Code
    
    Runwerte
    ID | Rettime | Plates |
    
    Run
    ID | HerstellerID | DimensionID | ResinID | RunID | Seriennr
    Das Gerüst habe ich bisher, für die Grafik würde dann ja
    Code:
    Rungrafik
    RunID | X | Y
    reichen, aber wie kann ich das sinnig unterteilen, dass ich ned so viele Werte in einer Tabelle hab.

    Kommentar


    • #17
      Und bitte noch kurz erklären was das für Daten sind. Etwas detailierter als "Messdaten" wäre nicht schlecht.

      aber wie kann ich das sinnig unterteilen, dass ich ned so viele Werte in einer Tabelle hab.
      Gar nicht, das soll/muss so sein. Die Referenzierung passiert über die ID und wenn du Daten brauchst dann fragst du ja mit WHERE gefiltert ab. Und wenn du dann noch die Indizes ("Indexe") korrekt setzt dann sind die Abfragen auch schnell.
      The string "()()" is not palindrom but the String "())(" is.

      Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
      PHP.de Wissenssammlung | Kein Support per PN

      Kommentar


      • #18
        Okay.
        Die Produkte sind Säulen, jede Säule ist einzigartig und wird über einen Zahlenschlüssel identifiziert:
        01 Hersteller
        01 Resin
        01 Dimension
        plus Seriennr der Säule. Von jeder Säule existiert genau eine Messung. Wenn ich zb eine Säule ausm Lager nehme steht da drauf 010101 Snr 1 (Damit kann ich genau sagen Welcher Hersteller etc)und in der Software gibt es auch eine Messung 010101_1, falls der Kunde die Messdaten anfordert, fertigen wir einen Report mit den Runwerten und der Grafik an um die Qualität dieser Säule zu belegen.

        Wenn ich die gar nicht unterteilen soll, gibt das dann mit der Zeit kein Problem mit der Menge? Es wären ja derzeit an die 30 mio Datensätze und werden tägl mehr, ich dachte das würde die Tabelle irgendwann nicht mehr mitmachen.

        Kommentar


        • #19
          . Von jeder Säule existiert genau eine Messung ... Report mit den Runwerten und der Grafik an
          Mit mehreren "Rungrafik" Datensätzen?

          Die Reiheinfolge der Rungrafik-Datensätzen je Säule(!) ist vermutlich auch relevant?

          Code:
          Rungrafik
          RunID | X | Y
          The string "()()" is not palindrom but the String "())(" is.

          Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
          PHP.de Wissenssammlung | Kein Support per PN

          Kommentar


          • #20
            Jede Grafik erzeugt zwischen 180 und 1800 Messpunkte (je ein x und ein y wert), ich bin jetzt von einem Datensatz pro Messpunkt ausgegangen.
            Das heisst Pro Messung 1 Datensatz in Runwerte und Run und zwischen 180 und 1800 Datensötze in Rungrafik

            Kommentar


            • #21
              Bei Mysql ist nicht die Anzahl der Datensätze das Problem sondern viel mehr die Limitierung des darunterliegenden Dateisystems. Wenn die Datei nicht grösser als 2GB sein darf, ist das bei Mysql die Grenze des Machbaren für die Tabellengösse.

              Aber warum nimmst du nicht Postgresql?

              Kommentar


              • #22
                Das heisst Pro Messung
                1 Datensatz in Runwerte und Run
                und
                zwischen 180 und 1800 Datensötze in Rungrafik
                Warum hier 3 Tabellen? Wenn du pro Messung einen "Stammdatensatz (Runwerte und Run)" und dann die vielen X und Y in "Rungrafik". Dh da würden zwei reichen?

                Kannst du ev. mal einen kompletten Beispieldatensatz liefern, für einen Säule mit wenigen (2 oder 3) X Y Werten dann kann man sehen was wie beziehungstechn. zusammengehört.

                Vor allem eben "Run", "Runwerte" und "RunGrafik".
                The string "()()" is not palindrom but the String "())(" is.

                Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                PHP.de Wissenssammlung | Kein Support per PN

                Kommentar


                • #23
                  @ Hausl du hast recht Run und Runwerte könnte bzw sollte eine Tabelle sein, da es ja pro Run auch nur 1x Werte gibt.

                  Code:
                  Run  ID | HerstellerID | DimensionID | ResinID | Seriennr | Rettime | Plates | T-Fact
                  hier mal exemplarisch Auszüge aus den 2 TxT Dateien:


                  1. Datei mit den Werten (010104_00044_run1_Det1_report.txt):
                  Ret.time Start End T-fact. N-plates
                  [min] [min] [min]
                  1 403.333 363.333 486.667 117.322 973.04

                  2. Datei für RunGrafik (zb: 010104_00044_run1_Det1_graph.txt):
                  0.000000 0.000000
                  0.016667 0.000000
                  0.033333 0.000000
                  0.050000 0.000000
                  0.066667 0.000000
                  0.083333 0.000000
                  0.100000 0.000000
                  0.116667 -0.012115
                  0.133333 -0.012174
                  0.150000 -0.017211
                  0.166667 -0.025466
                  0.183333 -0.026509
                  @ Protestix Ich habe bisher nur kleine Projekte Hobby mässig realisiert und kenne daher Mysql, kenne demnach Postgresql nicht. Was wäre denn der Vorteil daran?

                  Grüssle und vielen Dank für eure Geduld

                  Kommentar


                  • #24
                    Bitte Code Tags verwenden, man erkennt sonst nicht wo was dazugehört.

                    Gehört das so?
                    Code:
                         Ret.time     Start     End      T-fact.     N-plates
                         [min]        [min]     [min]         
                    1    403.333      363.333   486.667  117.322     973.04
                    The string "()()" is not palindrom but the String "())(" is.

                    Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                    PHP.de Wissenssammlung | Kein Support per PN

                    Kommentar


                    • #25
                      Zitat von hausl Beitrag anzeigen
                      Bitte Code Tags verwenden, man erkennt sonst nicht wo was dazugehört.

                      Gehört das so?
                      Code:
                      Ret.time Start End T-fact. N-plates
                      [min] [min] [min]
                      1 403.333 363.333 486.667 117.322 973.04
                      Sorry ja genau so gehörts

                      Kommentar


                      • #26
                        @ Hausl du hast recht Run und Runwerte könnte bzw sollte eine Tabelle sein, da es ja pro Run auch nur 1x Werte gibt.
                        So spontan.. Das klingt dann ja eh schon ganz gut. Du hast die Stammdaten der Säule wo du auf Hersteller etc referenzierst, dann - wenn es sicher nur eine Messung je Säule gibt - könntest du auch diese zu den Stammdaten der Säule geben, sonst eigene Tabelle (dann bist du flexibler und hast nur einen JOIN mehr) und dann die Messwerte die auf die Säule bzw. auf die Messungs-Stammdaten referenzieren.
                        The string "()()" is not palindrom but the String "())(" is.

                        Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                        PHP.de Wissenssammlung | Kein Support per PN

                        Kommentar


                        • #27
                          Über Indexe etc muss ich mich erstmal schlau lesen aber das Gerüst meiner DB würde dann so aussehen:

                          Code:
                          Hersteller
                          Id | Name | Code
                          
                          Dimension
                          ID | Name | Code
                          
                          Resin
                          ID | Name | Code
                          
                          Rungraph
                          RunID | X | Y
                          
                          Run
                          ID | HerstellerID | DimensionID | ResinID | RunID | Seriennr| Rettime | Plates | T-Fact

                          Kommentar


                          • #28
                            Benenne am Besten alle Spalten in englisch und Kleinbuchstaben. Das Minus lass weg wenn du ein Sonderzeichen nimmst, dann das Underline. t_fact
                            Und Bei rungraph nenne die id auch id und nicht runid. Die Fremdschlüssel würde ich resin_id rund_id etc.. nennen. Weiß nicht ob es da einen Standard gibt aber ich finde das sieht man sehr oft. Jedenfalls mit der einheitlichen Sprache solltest du arbeiten. Der Rest ist e.v. auch Geschmackssache.

                            Wenn du bei MySQL bleibst auf jeden Fall die InnoDB Engine verwenden und zu den Foreign Keys (Fremdschlüssel) findest du vieles im www zB https://www.w3schools.com/sql/sql_foreignkey.asp
                            The string "()()" is not palindrom but the String "())(" is.

                            Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                            PHP.de Wissenssammlung | Kein Support per PN

                            Kommentar


                            • #29
                              Skadie
                              Nachdem eigentlich schon alles gesagt ist noch ein etwas anderes Licht drauf:

                              30 Mio Datensätze:
                              Die Größe der Tabelle wird nicht das Problem sein. Es gibt keine komplexen Joins, Aggregatabfragen und keine komplexen Suchanfragen auf Deinen Datensätzen. Wenn ich es richtig verstanden habe, wird per Report ein Run abgefragt, also max 1800 Datensätze und fertig.
                              An dieser Aufgabenstellung und der benötigten Antwortzeit ändert sich auch bei einer großen Tabelle nicht viel. Die Indizierung erlaubt eine gezielte Abfrage.
                              Du kannst es einfach ausprobieren und 30 Mio Fantasiewerte in eine Tabelle schreiben, bei der RunId musst Du natürlich etwas gezielter arbeiten, um auf vergleichbare Teilmengen von 1800 zu kommen.
                              Du wirst sehen, das ist kein Problem.

                              Normalisierung:
                              Auch wenn "Normalisierung" meist der Standardruf des Entwicklers ist, hier bei der Messwertablage gibt es Argumente für wenig(!) Normalisierung. Kurz: Du wirst keinen einzelnen Datensatz oder Wert aus den Daten verarbeiten, sondern immer eine Messstrecke en bloc auslesen. Das spricht für eine Dokument basierte Datenspeicherung (der Einzelmesswerte), also alles in einen Topf, natürlich der Reihe nach, pro Messung.
                              Die Hinweise wurden hier auch schon genannt, json objects oder array. Damit kannst du dann Deine 30 Mio durch 1800 teilen. Und hast nur eine Tabelle mit 17000 runs bzw. Messläufen.
                              Das gilt natürlich nur, wenn wirklich nicht wahlfrei auf Einzelmesswerte außerhalb des Messkontext zugegriffen werden muss. Wenn keine Kumulationen ala gewichetes Mittel usw. veranstaltet werden sollen oder auch Messung übergreifend analysiert werden soll.
                              Wenn das also nicht der Fall ist, kannst Du Dir z.B. auch einfach mal vorstellen, was eine Normalisierung im Sinne von Speicherplatz bedeutet: Für 2 Messwerte brauchst Du zusätzlich immer die Referenz ID auf Run, 1 Drittel der NettoDaten sind also nur Hilfsdaten (Index noch nicht eingerechnet).
                              Etwas Charme hat sowas (JSON) auch bei den angedeuteten Reports. Wenn die Messwerte angefordert werden, einfach als Json in eine Textdatei und fertig. Bekommst Du per Fingerschnipp aus der Datenbank raus und der Kunde wird sicher mindestens ein Tool finden, das wieder einzulesen, notfalls Notepad. (Datensicherheit im Sinne von Aufbewahrungspflichten und schlichter Zugriffsmöglichkeit ist ja langsam auch ein Thema) Er muss nicht Eure DB oder irgendein a..teures ETL oder was auch immer verwenden.
                              JSON hat natürlich auch was Overhead, also abwägen, was einem wichtig ist. Vielleicht json nur für Export / Transfer. Übertragung aus Messprogramm per CSV (ist mit einem SQL Befehl eingelesen), Speicherung in der DB als Array oder oder

                              Gut, lass Dich davon nicht verrückt machen, sind nur ein paar Gedanken, die wenigstens mal gelesen haben solltest.
                              Der normalisierter Ansatz ist sicher kein Problem, auch nicht bei 30 oder 60 Mio Datensätzen.

                              Achso noch was vergessen:
                              Relationale Datenbanken haben ja auch gern den Zweck, Daten zu bearbeiten und zwar konkurrierend und transaktionssicher. Dafür wird ein enormer Aufwand getrieben, technisch, innerhalb der DB, das kostet Platz und Rechenleistung.
                              Bei Messwerten ist aber genau das nicht nötig, niemand editiert sie und schon gar nicht konkurrierend. Ein RDBMS wird eigentlich erst nötig, wenn man die Messwerte analysieren will, da macht eine DB natürlich Spaß. Ein Anfang ist natürlich auch schon die komfortable Suche nach Produktnamen usw., um Messungen überhaupt zu finden.

                              Kommentar

                              Lädt...
                              X