Urlaubsanträge von - bis Datum

[MzKlMu]

Hallo,
dann fangen wir mal an:

Da muss doch jedes Jahr der Kalender definiert werden.......

den Kalender legst Du einmalig für die nächsten 50 Jahre an. Geht automatisch, siehe Beispiel. Es müssen dann nur die Feiertage/Arbeitsfreitage je Jahr angehakt werden, ca. 10-15 Haken je Jahr. Die Tabelle wird nur 1x benötigt, nicht !! für jeden Mitarbeiter. Für die nächsten 50 Jahre sind das 18628 Datensätze. Das ist eine Kleinigkeit.

Auch festgelegte Betriebsschließungstage könnte man in die Funktion einbauen.

Eben, der Admin der DB muss jedes mal die Funktion anpassen.  Eventuell wird auch während des Jahres noch ein arbeitsfreier Tag (Betriebsausflug) geändert/eingefügt, was zu Folge hätte dass die Funktion angepasst werden muss. Bei einer zentralen DB hätte man eine MDE, was folgendes erfordert: MDB ändern > MDE erstellen > neu verteilen.  Stelle Dir jetzt mal den Aufwand vor?
Bei meiner/unserer Version => Formular aufrufen (Formular ist im Beispiel) , Haken setzen fertig. Die Datenänderungen erfolgen ausschließlich bei den Daten, nicht auf Programmierebene.

1 Mitarbeiter * 365 Tage, ok. Sagen wir mal 400 Mitarbeiter * 365 Tage = 146.000 DS ?? Warum nur ?

Das ist ohnehin ein Trugschluss, 365 DS je Jahr = wie gesagt 18628 DS für 50 Jahre. Die Mitarbeiterzahl spielt keine Rolle. Der Kalender gilt für alle.
Der Code für das Anlegen der Kalendertabelle ist auch im Beispiel, 50 Jahre dauern exakt 1,8 Sekunden.

Und dann kommt noch die Performance dazu. Um bei den 400 Mitareitern zu bleiben.
Stelle Dir vor Du willst für alle Mitarbeiter die Urlaubstage eine Jahres ermitteln:
Du musst für jeden Zeitraum und jeden Mitarbeiter über die Funktion (auch mit den Feiertagen) die Urlaubstage errechen. Und dann nach Mitarbeiter gruppieren.

Diese Abfrage rödelt noch, da bin ich mit meiner Version schon vom Mittagessen zurück.  

Übrigens, auch professionelle Programme arbeiten mit Kalendertabellen, teilweise sogar für jeden Mitarbeiter. Z.B. die Prjektplanung von MS "Microsoft Projekt".

[ebs17]

@69bruno:

Die Grundfrage dürfte lauten: Was ist schneller, weniger aufwändig, variabler, besser pflegbar?
1) die jedesmalige Neuberechnung oder
2) das Nachschlagen in einer Tabelle,
ob ein Datum Feiertag ist, Wochenende ist, in einem Schaltjahr liegt, in einer ungeraden DIN-Kalenderwoche liegt usw.

Zuerst wird man das bevorzugen, was man besser versteht, und da ist VBA mit seinen einfachen Befehlsabfolgen naheliegender als SQL, wo man mit Mengen umgeht. In einer Datenbank und für einen Entwickler darf das aber weniger Kriterium sein, wenn der Schwerpunkt auf einer effektiven Lösung liegt und nicht auf einem einfachen Weg hin zu einer Lösung.

Bei einer oder wenigen Berechnungen dürfte die Entscheidung ergebnisoffen sein, bei vielen oder sehr vielen Berechnungen wird dann die Nachschlagelösung die effektivere sein, um so mehr, je besser man Nachschlagen beherrscht.
Nachschlagen = optimale Abfragen auf optimale Tabellen

Natürlich ist das Vorabbereitstellen einer Kalendertabelle ein gewisser Aufwand. Mit der oben gezeigten Abfrage zeigte ich aber schon, dass eine solche Tabelle sehr zügig gefüllt werden kann. Aus einem Datum berechnete Werte wie Wochentag, DIN-Kalenderwoche, Quartal uva. kann man in der Kalendertabelle ablegen und zum Nachschlagen bereitstellen.
Und da man Feiertage berechnen kann, kann man das auch einmalig machen und diese Ergebnisse in einer Tabelle ablegen, wahlweise in der Kalendertabelle oder in einer eigenen Tabelle. Die Thematik Feiertage ist eh eine besondere, da Feiertage regional unterschiedlich sind. Im Zweifelsfall weiß ich als Entwickler (und als Bediener sowieso nicht) nicht, ob in einem  bestimmten Bundesland Allerheiligen und Rosenmontag Feiertage sind oder nicht. Im Zuge der Globalisierung sollte man sogar Feiertage in anderen Ländern berücksichtigen können (Terminlieferungen!). Ich schätze mal, dann wird es sehr eckig mit reinen VBA-Funktionen und deren Aufrufen. Selbst eine Feldschmiede kann heutzutage eine Filiale in einem anderen (Bundes)Land haben. Das sollte man verwalten können.

Zusammengefasst: Die Verwendung eines einmalig berechneten Kalenders ist eine sehr praktikable Lösung. Wenn ich vor der Nase einen Tischkalender liegen habe, komme ich eher nicht auf die Idee, das Datum des nächstdritten Montags (ersatzweise Dienstag, wenn Montag Feiertag ist), im Computer zu berechnen, sondern ich schaue auf das geduldige Papier.

Ein Kalender als Tabelle ist natürlich einmalig zu berechnen und zu erstellen und nicht für jeden Mitarbeiter.
Mitarbeiterkalender erhält man über ein simples Kreuzprodukt:

Code [Auswählen] Erweitern

SELECT K.Kalendertag, M.MitarbeiterID
FROM Kalendertabelle K, Mitarbeitertabelle M
In eine solche Abfrage kann man dann wieder ziemlich einfach individuelle Arbeitszeitmodelle einfließen lassen, die man geeignet in Tabellen festgehalten hat.

Ein weiterer Pluspunkt für eine Kalendertabelle wäre die Thematik Abfragegeschwindigkeit. Wenn ich in einer Abfrage (wie das MzKlMu in seinem Beispiel macht) einen Ausdruck YYYYMM als zusätzliches Feld berechne und danach filtere, habe ich wegen dieser Berechnung keine Indexnutzung bei der Filterung und damit verschenkte Performance.
Habe ich dieses Feld YYYYMM jedoch vorsorglich in meiner Kalendertabelle angelegt und indiziert, kann ich mir in einer beliebigen Abfrage über eine Verküpfung über den Kalendertag dieses indizierte Feld hereinholen und verwenden. Durch den nun nutzbaren Index werden trotz dieses "Umweges" Vorgänge wie Filtern, Gruppieren, Aggregieren und Sortieren auf dieses Feld deutlich schneller ablaufen können.

Also: Mit dem einmaligen Aufwand Kalendertabelle kann man sehr viel mehr Probleme lösen als das Zählen von Arbeits- oder Urlaubstagen, womit sich Aufwand relativiert.

MfGA
ebs

[MzKlMu]

Hallo,
@Ebs17

Code [Auswählen] Erweitern

Wenn ich in einer Abfrage (wie das MzKlMu in seinem Beispiel macht) einen Ausdruck YYYYMM als zusätzliches Feld berechne und danach filtere,
Diese Filterung dient ja jediglich zur Einschränkung der Daten im Formular zum einfacheren Anhaken. Und da spielt die Performance keine so große Rolle. Selbst mit den 50 Jahren ist da ein Monat innerhalb eines Augenzwinkern gefiltert.
Für die Berechnung der Urlaubstage ist das ja gar nicht notwendig.
Nur nebenbei.
Prinzipiell hast Du natürlich recht, es kann ja nur von Vorteil sein, wenn man um diese Dinge weis und auch anwendet.

[Bernie110]

@Ebs

Kannst Du erst einmal erklären, wozu genau Du eine Tabelle benötigst, in der alle Urlaubstage einzeln drin stehen.
(Erst der Plan, dann gezielte Aktion.)

In meiner DB gibt es auch einen Schichtplan.
in diesem Schichtplan stehen Daten wie ... Arbeits_Beginn , Arbeits_ende..Pause usw.

In diesem Schichtplan sollen die Urlaubstage, die beantragt bzw genehmigt worden sind berücksichtigt, werden.

Ein Feld Namens "Bemerkung" besagt, ob der User im Urlaub, Krank oder Abwesend ist )

Da es im Schichtplan für jeden Tag ein eigener DS je Mitarbeiter & Datum gibt , ist es für mich und meine Accesskünste ein leichtes dies abzugleichen.
Natürlich auch wieder mit einer Schleife.

Wenn man das besser machen kann..für Tipps ( die ich auch verarbeiten kann ) bin ich immer dankbar.

Gruss
Bernie

[MzKlMu]

Hallo,
auch dazu ist die Kalendertabelle hilfreich. Du kannst über eine Anfügeabfrage die zwischen den Grenztagen liegenden Daten der Kalendertabelle entnehmen und anfügen.

Ein Feld Namens "Bemerkung" besagt, ob der User im Urlaub, Krank oder Abwesend ist

Das würde ich nicht in das Feld Bemerkungen schreiben, sondern in ein extra Feld aber als Schlüsselzahl (1=Urlaub, 2=Krank etc.)

[ebs17]

Diese Filterung ...

... war auch nur ein Beispiel, um kein eigenes darstellen zu müssen.

Nachdenkenswert ist der Einwurf aber auch: Kann ich im Vorfeld (bei Entwicklung) einschätzen, ob eine beschränkende Lösung (nach eigenen Kenntnissen und Erfahrungen) genügt oder sollte ich stets bestrebt sein, bei vertretbarem Aufwand das Beste zu installieren und zu verwenden?

Zuviel vorhandene Performance kann man notfalls mit ein paar Spielchen abmildern. Nachträglich Performance gewinnen zu wollen bedeutet recht oft erheblichen Aufwand. Umbau der DB?

@bernie:

im Schichtplan für jeden Tag ein eigener DS je Mitarbeiter & Datum

Das würdest Du dann benötigen, wenn Du jeden Datensatz einzeln und händisch bearbeitest, also quasi eine persönliche Anwesenheitskontrolle führst, mit Anhaken und so.
Ansonsten genügt das Festhalten von Zeiträumen (Urlaub von-bis, Krankheit von-bis, Dienstreise von-bis ...). Eine Tagestabelle erhält man dann durch einen einfachen Abgleich zwischen Kalendertabelle und Zeitraumtabelle, bspw. (vereinfacht) ...

Code [Auswählen] Erweitern

SELECT K.Kalendertag AS Urlaubstage
FROM Kalendertabelle K, Zeitraumtabelle Z
WHERE K.Kalendertag Between Z.von AND Z.bis
AND Z.Art = 'Urlaub'

MfGA
ebs

[69bruno]

Das:

Eben, der Admin der DB muss jedes mal die Funktion anpassen.  Eventuell wird auch während des Jahres noch ein arbeitsfreier Tag (Betriebsausflug) geändert/eingefügt, was zu Folge hätte dass die Funktion angepasst werden muss. Bei einer zentralen DB hätte man eine MDE, was folgendes erfordert: MDB ändern > MDE erstellen > neu verteilen.  Stelle Dir jetzt mal den Aufwand vor?
Bei meiner/unserer Version => Formular aufrufen (Formular ist im Beispiel) , Haken setzen fertig. Die Datenänderungen erfolgen ausschließlich bei den Daten, nicht auf Programmierebene.

ist es in meinen Augen. Ist mir nicht aufgefallen, da ich auch thematisch die DB verwalte, sprich ich bin Personaler, der nebenbei DB' bastelt, um sich arbeit zu erleichtern. Sollte ich mal weggehen, könnte das zum Problem werden 

Die Performance wäre bei meiner Methode nicht ganz so entscheidend, weil die Funktion angestoßen wird, wenn der Zeitraum von bis eingegeben wird. dann wird ein weiteres Feld befüllt.

Jetzt muss ich mal überlegen, ob ich die DB doch änder, damit der User sie ohne Adminunterstützung auch anpassen könnte...... 
Danke!

[Bernie110]

@ Ebs

Das würdest Du dann benötigen, wenn Du jeden Datensatz einzeln und händisch bearbeitest, also quasi eine persönliche Anwesenheitskontrolle führst, mit Anhaken und so.

Genau um das gehts ! ;-)

[MzKlMu]

Hallo,
dann passt ja auch meine vorherige Antwort.