Office: (Office 2003) Datum addieren ohne Wochenende

Wie sehen das denn eigentlich die anderen Experten?

 

In meinen Anwendungen verwalte ich nicht nur die Feiertage eines Bundeslandes, sondern mehrerer.

Da macht nur eine Jahrestabelle Sinn: Fortlaufendes Datum in den Zeilen, Bundesländer in den Spalten und Boolscher Wert im Schnittpunkt (Feiertag ja oder nein).

So etwas ist jährlich manuell (ohne Feiertags-Formeln) zu pflegen. Das macht zwar einen gewissen (jährlich einmaligen) Aufwand, ist aber mit etwas Erfahrung und Clevernes beim Editieren aus meiner Sicht eine gute und fast fehlerfreie Methode. *wink.gif* Die entsprechenden Kalender gibt's für mindestens 2 Jahre im voraus im Web.

Im Sinne der Normalisierung könnte man auch so programmieren:

31.10.09 NRW FALSE
31.10.09 SAC TRUE

 

Hallo zusammen,

@Martin: mal schauen, ob Deine Lorbeeren

bei mir gerechtfertigt sind *tongue.gif*

Wenn ich vor derselben Problematik stehen würde, zukünftige, periodische
Prüftermine zu ermitteln, ob diese auf einen freien Tag fallen oder nicht,
dann käme für mich ausschließlich die Lösung einer "Feiertagstabelle" zum Einsatz, da

Feiertage IMHO zu Stammdaten gehören, welche jede Firma für sich pflegen muss
(Hintergrund die bereits beschriebene 5. Jahreszeit oder Werksferien oder
Chef hat Geburtstag oder (noch besser) Chef ist gar nicht da *grins oder ...)

Hier würde ich zum Ende eines Jahres / Anfang eines Jahres (bzw. einer Periode)
dem Anwender per "Formel" Vorschläge für freie Tage erzeugen, welche er
übernehmen, ändern und ergänzen kann.

 

Okay, richtig ... dann ist aber nicht relevant das es ein Feiertag ist, sondern das es kein Arbeitstag ist.

Sehe ich etwas zwiespältig. Was erfasst Du zu einem Produkt X der im Jahr so und so zu einem Preis so und so verkauft wurde?

Eine Rechnung richtig, aber erfasst Du zu dem Produkt selber das es an dem Datum zu einem BRUTTOPREIS von XYZ verkauft wurde? Nicht wirklich, Du erfasst einen Ausgang des Typus Verkauf und Ende der Geschichte. Aus der verknüpften Tabelle kannst Du dann im Nachgang feststellen welcher Netto-Preis zum damaligen Datum galt und aus einer anderen Tabelle welcher MWST-Satz gültig war und aus einer anderen Tabellen ermittelst Du ob bei dem Vorgang Rabatte zum tragen kamen. Dadurch kann man auch noch den exakten Verkaufspreis nach Jahrzehnten ermitteln.

Und in einem Code zu verknüpfen das ein Feiertag nur von Jahr bis Jahr gilt, ist ja jetzt wohl das einfachste überhaupt. *wink.gif*

Und zum Thema Fehleranfälligkeit:

Handeingabe ist doch wohl eindeutig die größere Fehlerquelle. *wink.gif*

Wie schon gesagt, erstens sind einige weitere Feiertage von Ostern abhängig und daher brauchst Du die Rechnung wann Ostern ist.

Aber genau deswegen, weil Feiertage eben konstant sich jedes Jahr ändern vom Datum her (mal unabhängig von der Gesetzgebung) gehören sie irgendwie nicht in eine Tabelle weil sie eben nicht feststehen.

Klar, wenn Du eine DB für einen bestimmten Betrieb und auch nur für diesen Betrieb betreibst ist das mit Sicherheit okay. Aber wenn Du etwas entwickelst was verschiedene Betriebe in verschiedenen Regionen nutzen sollten dann wird es eng im Karton mit dieser Methode.

Die Methode der Handpflege von Arbeitstagen pro Jahr kann nicht generalisiert werden.

Was mir eben auch noch an der Vorgehensweise nicht behagt ist, dass dadurch ein Tag zu einer Entität wird. Klar kann man es auch nur als reines LookUp-Table betreiben.

Wie gesagt, ich stehe eher auf dem Standpunkt das man sofern es gültige Grundregeln gibt von diese ausgeht und nur die Besonderheiten erfasst sofern nötig.

Und für eine reine Ermittlung ob ein Tag zur Eintragung eines ToDo's ein Feiertag ist oder ein Wochenende ist mMn nach die Anlage eines reinen Tables für das Jahr nicht gerechtfertigt.

Wenn man sowas eh von Jahr zu Jahr pflegen muss, dann ist es schlicht einfacher eine Zeile im Code zu ändern falls sich ein Feiertag verändert hat und ansonsten alles automatisiert laufen zu lassen. Ein korrekt geschriebener Code ist einfach sicherer als jedes Jahr auf's Neue Handeingaben zu machen.

Aber okay, ist mit Sicherheit wie vieles Ansichtssache und auch Geschmacksfrage. *wink.gif*

Gruß

Rainer

 

\@Martin
Deine Argumentation ist sachlich korrekt und souverän vorgetragen.
Schulferien sind auch noch so etwas, das sich nicht errechnen läßt. Mit einer Kalendertabelle sind die aber einfach zu verwalten.

 

Ich weiß nicht ob ich ein Experte bin, aber alle Vorschläge sollten sich auch danach richten was denn an dem Prüfdatum geleistet werden soll.
Wenn mit den Eigenschaften der Daten (Plural Datum) gearbeitet werden soll, gehören diese in eine Kalendertabelle.
Wir haben bei uns den sogenannten Industrie- Produktions-, Messekalender, usw. Diese werden Zentral geführt.
Jeder der nun will kann seine Termine mit Diesen abgleichen.
Ich denke das ist bei jeder ernsthaften Datenbank der Standard.
Grundsätzlich halte ich, wie bereits gesagt, bei Prüfterminen eine Lösung mit Karenztagen für das Beste.

 

Ein weiterer Aspekt wurde noch nicht beleuchtet:

Wer sagt denn in diesem oder in anderen Fällen, dass es nur um ein Datum geht? In einer Datenbank geht es recht oft um mehrere (viele?) Datensätze und evtl. um eine Reihe von davon abhängigen Berechnungen.

Die relativ statische Berechnung von Feiertagen kann man nun in Abfragen x-fach wiederholen oder einmalig als Zwischenergebnis in einer Tabelle ablegen. Aus reinen Performancegründen neige ich dann zur Tabelle.

 

Also mal so ganz nebenbei .... MOMENT bitte. *wink.gif*

Ausgangspunkt war ob es notwendig ist eine Tabelle mit Kalendertagen zu führen um nur Wochenenden und Feiertage festzustellen.

Wir sind jetzt aber mittlerweilen bei Produktions- und Messekalendern angelangt an die sicherlich andere Anforderung zu stellen sind als an die einfach Betrachtung ist das ein Arbeitstag ja oder nein. *wink.gif*

Von daher gibt es hier wohl viele Wahrheiten, aber keine einzige die auf alle verschiedenen Anforderungen gleich passt.

Da gibt es ja keinen Zweifel.

Aber führst Du wirklich in jedem dieser Kalender alle 365 Tage des Jahres auf? Was im Sinne von Rednunanzen in den Entinitäten nicht wirklich sinn macht.

Aber auch bei sowas ist die Frage ob man dafür wirklich alle Tage an denen nichts ist als Leer-Container für möglicherweise eventuell kommende Einträge mitführen muss.

Irgendwo hat mal einer von den Experten hier geschrieben, dass man keine DS anlegen sollte wenn man sie noch nicht braucht. Ich glaube sogar das warst Du @ Atrus. *wink.gif*

Und einen leeren Kalendertag als DS anzulegen der erstmal keine Relevanz hat würde für mich genau darunter fallen.

Zumindest in dem vorliegenden Falle geht es um eine Einzelbetrachtung für ein Datum.

Und zweitens wieviele gleichgelagerte Datumsabfragen müssten durchgeführt werden, bis der Geschindigkeitsnachteil beim Zugriff auf ein Server gelagertes Backend ausgeglichen, bzw. sich in einen Vorteil verwandelt?

Ich weiss es nicht, aber da reden wir dann aber wahrscheinlich über sehr große Größenordnungen. Und da hast Du dann absolut Recht, da macht ein Zwischentabelle oder sogar eher noch ein Disconnected/ungebundenes Recordset am ehesten Sinn.

Aber da ist dann auch wieder die Frage ob dafür zwingend eine Tabelle mit per Hand eingetragenen Feiertagen notwendig ist oder ob man bei sowas nicht einmal die Feiertage für das Jahr berechnet und in die Zwischentabelle oder das Recordset knallt.

Aber ich denke wir können hier weiter diskutieren ohne auf einen gemeinsamen Nenner zu kommen, denn es gibt je nach Aufgabenstellung unterschiedlichste Anforderungen und jede dieser Anforderung benötigt dann wahrscheinlich eine eigene Lösung. *wink.gif*

Gruß

Rainer

 

Das weiß ich garnicht. Die Daten werden mir bei Betrachtung als Kalender angezeigt. Ahnlich Outlook
Bei Zugriff auf die Daten geschieht über eine Abfrage deren Ergebnis mir meine Daten zeigt und u.U. die gespeicherten Termine. Wo kein Termin vorhanden, wird nix angezeigt. aber erst hier erscheinen für mich leere "Container"

Zum Thema Sa So>>>Karenztage!

 

Wer spricht denn (außer Dir) davon?

 

Das ist einfach beantwortet: es geht um ein Vielfaches schneller bei Auswertungen, da man in so eine Kalendertabelle ("Werkskalender") nicht nur die Feiertage bzw. arbeitsfreien Tage eintragen kann, sondern auch noch die Kalenderwoche usw. ... also eigentlich eine besonders schlimm gestaltete Tabelle mit redundanten Daten. *wink.gif*
Das hat aber dann auch den Vorteil, dass man einen konkreten Datumswert zum Verknüpfen in Abfragen hat und so z. B. sehr schnell die Lieferpositionen der Montage im Monat Mai über die Jahre 2007 bis 2009 auflisten kann.

Oder wenn du die Frage stellt, wie viele Werktage (also Wochentage ohne Feiertage, Betriebsurlaub usw.) zw. dem 23.4.2009 und 27.9.2009 liegen, reicht ein einfaches Count(*) mit dem Datumsfelder und schon hast du die Antwort.
Ich lasse mich aber gerne überzeugen, dass es anders besser geht, wenn du mir eine VBA-Variante zeigst, die diese Auswertungen schneller durchführt.

Anm.: Da wir hier alle Datenbankanwendungen erstellen, gehe ich von Massendatenverarbeitung aus und nicht vom Prüfen von Datumswerten in Schleifen. .. das macht hoffentlich kein Datenbanker. *wink.gif*

 

Hallo,

@Rainer

ganz am Anfang in #2 wurde von doch von Martin der nicht von der Hand zu weisende Einwand

eingebracht.

Ich denke, dass die weitere Diskussion dies aufgenommen und verfeinert hat.

Also bspw. nicht nur Pfingsten, sondern auch lokale Feiertage usw. ...

Hier werden glaube ich 2 verschiedene Ebenen der "Problemlösung" diskutiert,
nämlich einmal die einfache Variante 1 "Arbeitstage ohne Sa und So" aus #1
und die erweiterte Lösung / Variante 2 "Arbeitstage ohne Sa und So und noch weitere freie Tage" aus #2 ff.

IMO haben die Befürworter der beiden unterschiedlichen Lösungsansätze eine korrekte Lösung
vorgebracht, jedoch jeweils auf Basis der unterschiedlichen Ausgangslevel
des Problemverständnisses. *wink.gif*

 

Hi,

*grins da hab ich ja wieder was losgetreten.

Vermutlich ist folgendes konsensfähig:
es kommt auf den Anlass an, was sinnvoll ist. Wie fast alles im DB-Design. *Smilie

@raist:
Die 365/366 Tage des JAhres sind aber auch in der Kalendertabelle nicht Ballast, sondern Plangröße. z.B. bei einer Terminserie ("immer dienstags") könnte ein rechnerischer Termin auf einen Nichtarbeitstag fallen, und dann könnte man eine Offsetregel ("Werktag vorher" oder "Werktag nachher" als Eigenschaft der Serie definieren, die dann regelt, wie der Termin ausweichen soll. Dafür muss man auch im Januar wissen, dass am 03.10. frei ist.

Insofern sind das keine "Dummysätze", die irgendwann mal mit Leben gefüllt werden, sondern Einflussgrößen auf die Zeitplanung. Dein leerer papierener Terminkalender geht doch auch schon beim Kauf übers ganze Jahr, oder klebst du jeden Tag ein neues Blatt rein *Smilie

Um die Threaderöfnerin ist es indes ganz still geworden. Jemand da? *Smilie

 

\@raist:

Du kannst allenfalls feststellen, welcher Preis damals gültig gewesen sein müsste ("History by Lookup" mit Artikelnummer, Preis und Gültiogkeitszeitraum). Wenn aber ein betrügerischer Anwender in diese History einen Datensatz "reinschummelt", der zufällig bestimmte Eigenschaften hat, kann er damit erreichen, dass damals ein anderer Preis gültig gewesen sein müsste. Quasi eine "Zeitreise". Damit rechnet er den Umsatz gegenüber den Finanzamt klein, versteuert 3,80 EUR und stellt danach die Geschihcte wieder richtig, um die betriebswirtschaftliche Analyse nicht zu verfälschen *Smilie

Die Historytabelle ist trotzdem mitunter sinnvoll. Denn wenn man nur (durch "History by Backup") die Preise speichern würde, zu denen auch Absatz erfolgte, könnte man nicht feststellen, wie elastisch die Nachfrage auf die Preise reagiert:

Jahr 2007: Artikel kostet 50 EUR; 3000 Einheiten verkauft
Jahr 2008: Artikel kostet 90 EUR: 0 (!) Einheiten verkauft.
Jahr 2009: Artikel kostet 60 EUR: 2400 Einheiten verkauft

In der Backuplösung würde für 2008 einfach kein Absatz-Datensatz existieren, und es wäre nicht unterscheidbar, ob der Umsatzrückgang wegen eines (nicht mehr erkennbaren) hohen Preises oder aus anderen Gründen stattfand.

Die Backuplösung macht aber wiederum möglich, in Einzelfällen auch andere als die Listenpreise anzusetzen (Rabatt, Kulanz, ...). Der Historyansatz könnte das nur über Ab/Zuschläge oder Prozentfaktoren, die aber wiederum beim Backupanasatz ebenfalls möglich sind.

WIe mans halt braucht. Die geilste Datenbank ist eh die Realität: super Performace (Echtzeit), tolle Grafik, und solange die Zeitmaschine nicht erfunden ist, ist die Vergangenheit buchstäblich Geschichte und kann nicht geändert werden. Ein Archiv ihrer selbst.

Schönes Thema für den philosophischen Gesprächskreis MOF. *winken

 

Ich war wohl auch nicht ganz unschuldig dran. *g*

Okay, viele tolle Argumente und Einwände ... jetzt auf die Schnelle drauf einzugehen würde dem Niveau der Diskussion nicht gerecht.

Also ... morgen werde ich mich dann ausführlicher äußern.

Aber nur soviel auf die Schnelle:

Danke Josef, hatte schon gedacht das ich völlig Banane bin. *wink.gif*

Gruß

Rainer