SQL View historisieren

[Mr. Robot]

Hallo zusammen,

es ist lange her das ich mich mit SQL und Historisierung beschäftigt habe. Hoffe daher auf eine kleine Starthilfe.

Ich möchte über eine Abfrage eine neue Tabelle (View) erstellen. Diese Tabelle soll dann über das ganze Jahr statisch bleiben. Die statische Tabelle möchte ich dann mit weiteren Spalten aus derselben oder andrer Tabellen anreichen. Diese neuen Spalten wären dann dynamisch und würden u.a. die Veränderungen zu der statischen Tabelle aufzeigen.

Wie geht man hier am besten vor? Kennt jemand eine passende Webseite mit den nötigen SQL Befehlen?

Vielen Dank!

Viele Grüße
Mr. Robot

 

[dabadepdu]

mmh, weiß nicht, ob ich das richtig verstanden habe.
Du schreibst eine View, die lässt Du ein Jahr laufen. Dann erweiterst Du sie.
Oder
Du schreibst eine Schwesterview, die den ersten Teil stumpf abfragt und neue Teile (Spalten ergänzt)

Die View würde ich so aufbauen, dass ich auch außen auf alle Schlüsselfelder Zugriff habe und damit alles ergänzen / überall andocken kann, ohne mich (die View) zu verbiegen.

 

[t-sql]

Ich mach das mit zwei Tabellen und einem Diff.

 

[ukulele]

Kannst du das vielleicht irgendwie in ein Beispiel packen? Gerne auch mit Autos oder so

Ich stelle mir das jetzt mal so vor du hast z.B. einen Planumsatz der gilt 1 Jahr (=feste Tabelle für alle Jahre, eine Spalte definiert das Jahr). Dazu joinst du ein Aggregat das die tatsächlichen, schon erbrachten Umsätze dazu holt (=Join sum() über GROUP BY z.B. aller geschriebenen Rechnungen). Eventuell soll das dann erweitert werden um die Möglichkeit die Annäherung des Ist-Umsatzes an den Soll-Umsatz zu zeigen (= Umsatz kommuliert über Rechnungsdatum).

Das geht auf jeden Fall alles...

 

[Mr. Robot]

Die Beschreibung von dir ukulele passt denke ich. Die erste Tabelle ist eine feste Tabelle die sich das ganze, aktuelle Jahr nicht mehr verändert. Als hätte man in der Datenbank eine Tabelle kopiert und in Excel hinzugefügt. Diese feste Tabelle soll über eine View erstellt werden (zumindest der einzige Weg den ich kenne eine bestehende Tabelle verändert abzuspeichern). Die View dürfte sich halt nur nicht mehr verändern.

Anschließend sollen weitere Werte hinzu gejoint werden wie von ukulele beschrieben. Diese sollen die täglichen Werte widerspiegeln. Als würde man die obige feste Excel Tabelle um eine weitere Spalte ergänzen und täglich manuell pflegen.

 

[ukulele]

Die Beschreibung von dir ukulele passt denke ich. Die erste Tabelle ist eine feste Tabelle die sich das ganze, aktuelle Jahr nicht mehr verändert.

Ich würde es etwas anders machen und nicht ein Jahr = eine Tabelle bzw. eine Tabelle die immer nur genau einem Jahr entspricht sondern grundsätzlich hast du eine Tabelle mit zwei Spalten, Jahr und Planumsatz (vereinfacht gesagt). Also eine Tabelle für alle Jahre, eine Zeile pro Jahr. Wenn sich der Umsatz dann aufteilt in mehrere Abteilungen oder was auch immer dann gibt es halt noch eine Spalte "Abteilung" und für jede Abteilung pro Jahr einen Datensatz.

Nur das ist sauber designt. Man macht keine Tabelle Planumsatz_2023, das ist ganz ganz schlecht.

Als hätte man in der Datenbank eine Tabelle kopiert und in Excel hinzugefügt. Diese feste Tabelle soll über eine View erstellt werden (zumindest der einzige Weg den ich kenne eine bestehende Tabelle verändert abzuspeichern). Die View dürfte sich halt nur nicht mehr verändern.

Views verändern sich grundsätzlich, feste Werte speichert man in Tabellen. Man kann ja mit einem Script zu Anfang eines neuen Jahres den Planumsatz aus dem Vorjahr übernehmen und dann ggf. die Werte anpassen. Irgendwoher müssen die Planumsätze ja sowieso kommen, eventuell gibt die auch einer manuell ein. Aber speichern tut man sie dann in einer Tabelle.

Anschließend sollen weitere Werte hinzu gejoint werden wie von ukulele beschrieben. Diese sollen die täglichen Werte widerspiegeln. Als würde man die obige feste Excel Tabelle um eine weitere Spalte ergänzen und täglich manuell pflegen.

Das geht wenn man zu jedem erfolgten Umsatz auch ein Datum hat, also zunächst mal Rechnungsdatum. Wenn es um einen Bilanzierer geht wäre noch Leistungsdatum relevant. Auch gibt es dann so schöne Sachen wie Vorschuss Rechnungen, Gutschriften, Rechnungskorrekturen, etc., man muss sich also anschauen wo die fakturierten Umsätze stehen.

Wenn die beiden Informationen, also Planzahlen um tatsächliche Umsätze bekannt und klar sind kann man relativ leicht eine passende View bauen die zeigt wie sich der tatsächliche Umsatz entwickelt.