Das kommt auf die Art der Daten an und wie weit man ins Detail gehen möchte.
Eine Messstation bleibt wahrscheinlich längere Zeit bestehen und wird immer wieder referenziert. Hier könnte man im einfachsten Fall sich irgendein Kürzel oder Zahl als Kennung ausdenken. Eleganter wäre aber ein Eintrag in einer Extra-Tabelle mit automatisch angelegter ID, auf die man dann woanders Bezug nehmen kann. Dann lassen sich auch weitere Details wie Standort oder Aufstelldatum / Datum der Inbetriebnahme mit einpflegen.
Und eine weitere Tabelle braucht man dann für die eigentlichen Messungen. Was man da als Details eintragen kann, wurde ja schon besprochen. Jede Messung sollte natürlich auch wieder automatisch eine ID zugeteilt bekommen. Zum Beispiel können diese IDs benutzt werden, um zu dokumentieren, welche Messungen in welchem Monat / Woche / Tag durchgeführt wurden, ohne dass man jedes Mal die komplette Messung eintragen muss.
Das Prinzip lautet hier: Sparsamer Umgang mit Ressourcen (Speicher) durch Vermeidung von Redundanzen (Wiederholungen). Als weiterer Effekt werden damit Änderungen an den Daten an allen Stellen sichtbar, da überall auf den gleichen Datensatz verwiesen wird und nur dieser Datensatz angefasst wird. Die dazu passende Struktur und wieviele Tabellen du dafür anlegst, musst du dir schon passend zum Anwendungsfall selbst ermitteln.
Hypec hat geschrieben: ↑Mittwoch 20. März 2019, 16:13
Also muss ich da dann immer 3 Tabellen abrufen um mir dann die Daten die ich haben will zusammen zubauen oder wie geht das ganze dann?
Na, das löst du halt beim Reporting auf. Der Leser interessiert sich ja weniger für die ID, sondern eher für den Namen oder Standort der Station. Das lässt sich dann passend einteilen, z.B. mittels
GROUP BY.
Du musst halt, wie so oft bei der Programmierung, in Rollen denken: Eine Rolle ist die interne Datenhaltung, wo man IDs benutzt. Die andere Rolle ist die Aufbereitung für Anzeige beim Anwender. Dass dann mehrere Tabellen ins Spiel kommen, ist ganz normal.
