Irknwie steig ich da nicht durch, mein PG akzeptiert das SQL leider auch nicht.
Ist ja auch SQLite nicht PG.
Jetzt zu Deinen Anmerkungen
Deine Tabelle 'gesamtuebersicht' wird durch einen TRIGGER befüllt, dieser arbeitet aber nur bei INSERT. Wenn Du in 'einzelplanung' was änderst / löscht, dann ist diese Tabelle natürlich Schrott. Ich denke, Du solltest aus dieser Tabelle einen VIEW machen.
Bisher hatte ich auch einen View. Der hat mir bei Aufruf beinahe den Rechner „blockiert“. Die Tabelle blockiert nur 1 x, Nachfolgende Einträge sind schnell über den Trigger verarbeitet.
warum der UNIQUE (bereich, Abteilung, name, vorname, EUR_Std, Std_Mon, Beginn, Ende) in 'einzelplanung'? Der macht zwar keinen Schaden, aber wohl auch keinen Sinn. Oder ich versteh diesen nicht, was natürlich durchaus wahrscheinlich ist
Dadurch werden Dubletten verhindert. Durch unsere interne Organsisation sind solche Dubletten ausgeschlossen. Außerdem siehe Oben.
schlechte Normalisierung. In 'einzelplanung' kommt immer wieder Dein Mustermann vor, hier wäre evtl. eine extra Personaltabelle sinnvoll und in 'einzelplanung' dann ein FK auf diese Personal-Tabelle
Stimmt. Ich arbeite direkt mit dem SQLite-Manager Mozilla. Kann also bei der Eingabe keine anderen Tabellen als Quelle verwenden. Ich selbst bekomme Informationen von verschiedenen Leuten, welche mit Datenbanken nichts am Hut haben. Auch erscheinen in den IST-Zahlungen die Kurzzeitbeschäftigten nicht so, wie über meinen Tisch gelaufen. Dafür habe ich mir in der Originaldatenbank einen View gebaut, welcher mir Name/Vorname-Kombinationen ausgibt, welche in meiner Plandatenbank und den Ist-Zahlen nicht identisch sind. Beispiel:
In einem Projekt soll ein Karl-Theodor zu Guttenberg beschäftigt werden. Ich gebe das O.K. für de Finanzierung. In der Personalabteillung wird dieser Kurzzeitbeschäftigte je nach Sachbearbeiter erfasst
- Guttenberg Karl-Theodor zu
- Guttenberg Karl-Theodor
- zu Guttenberg Karl-Theodor
- to be continued
Ich passe dann meine Tabelle Einzelplanung an und gut.
Deine 'monate' - Tabelle würde ich so gar nicht machen, aus einem Datum läßt sich immer berechnen, in welchem Monat / Halbjahr das ist
Die Tabelle gibt mir die Monate Zwischen Vertragsbeginn und Vertragsende heraus. Ich muss u.a. berechnen,
- wer
- wieviel
- in welchem Monat kosten wird.
Ich hatte da einmal einen Thread gestartet, bin aber nicht weitergekommen.
https://www.datenbankforum.com/threads/monatserste-in-perioden-ermitteln.1373/
Dein VIEW "v_monatsstunden" ist meiner Meinung nach syntaktisch falsch: alle Spalten der Select-Liste müssen entweder in einer Aggregatsfunktion sein oder im GROUP BY auftauchen
in DATETIME-Feldern speicherst Du lediglich DATE
Vielleicht nicht elegant, aber der View liefert mir die Informationen, welche ich benötige.
DATETIME ist die einfachste Möglichkeit das Datum zu speichern. Der TIME-Teil kann unter den Tisch fallen. Die GUI bietet für Zeiten lediglich DATETIME an.
Dein Std_Mon_G im VIEW v_monatsstunden aggregiert offenbar alle Daten aus gesamtuebersicht, nicht nach Monaten aufgedröselt.
Ich wüde sagen schon. Er liefert mir die Summe aller Stunden über alle Verträge hinweg je Person und Monat. Unabhängig vom Vertrag.
Ich bin mir nicht sicher, was total() macht, ich vermute sowas wie sum(), ist das korrekt?
Korrekt total() ist nahezu wie sum(), bis auf den Unterschied:
The result of total() is always a floating point value. The result of sum() is an integer value if all non-NULL inputs are integers. If any input to sum() is neither an integer or a NULL then sum() returns a floating point value which might be an approximation to the true sum.
Sum() will throw an "integer overflow" exception if all inputs are integers or NULL and an integer overflow occurs at any point during the computation. Total() never throws an integer overflow.
