Office: (Office 2010) Zeiträume in zwei Tabellen vergleichen

Nicht vollständig belegt (ungetestet):
Code:

Die Komplettbelegung (Frage1) würde sich aus der Umkehrung ergeben:
=> Restmenge = Tabelle1 abzüglich oben ermittelte Menge und Gruppierung zwecks Duplikatsvermeidung.

 

Das hier liefert mal alle Tage aus T1, die nicht in T2 sind:
Code:

 

Nö, leider nicht ... hatte ich ja auch erst probiert.
Aber der Ansatz mit den Unterabfragen, den Eberhard ja ebenfalls hatte, funktioniert.

 

Hallo!

Bei diesen SQL-Anweisungen sollte man sich meiner Meinung nach unbedingt wieder den Ablaufplan anschauen, um zu sehen, ob der optimiert durchgeführt wird.

Vielleicht es das aber auch nur mit SQL machbar.
Ich denke dabei an das Prinzip "Lücken" in einer Zahlenfolge zu finden. So ein Lücke wäre dann ein Signal, dass davor oder dahinter ein neuer Bereich startet.

mfg
Josef

 

Noch ein Hinweis an den TS:
Die Option, einen "Ende-offen" Zeitraum mit einem konkreten Datum im Jahr 9999 zu belegen, halte ich für unhandlich.
Mindestens hier in dem Beispiel bläht es die Kalendertabelle gewaltig auf (3 Mio. Datensätze).
Ich arbeite da lieber mit NULL im Feld bis ...

 

... vor allem auch auf die notwendige Indizierung achten (neben ID auch alle fünf Datumsfelder).

 

Dazu hätte ich dann noch ein paar Fragen.

Der Hinweis bezüglich dem Ende ist natürlich vollkommen richtig, das scheint auch der Grund zu sein warum die Abfrage teilweise nicht zum Ende kommt bei der Berechnung.

Wie gehe ich dann mit dieser "Null" im Ende-Datum bei Abfragen um? Oder erkennt Access von sich aus das das ein laufender Zeitraum ist? Oder sollte man lieber ein Datum in die Zukunft nehmen etwa 31.12.2018 ?

Und läuft das mit der Indizierung für die Datumsfelder?

lg und vielen Dank bis hier her schonmal *Smilie

 

Ein Datum in der Zukunft ist heute OK. Morgen könnte das schon wieder in der Vergangenheit liegen. Wenn es fest eingegeben ist.

Ich halte NULL für sinnvoll, wenn das Ende offen ist.
In Vergleichen muss das eben abgefangen werden.
In T-SQL gibt's dafür die Funktion ISNULL(), in JetSQL entsprechend NZ().
Die beiden Beispiele im Folgenden setzen das Feld bis auf das morgige Datum, wenn es leer ist: Code:

In Deinem Beispiel ist das nicht ganz so trivial, weil ja die Datensätze mit festem Ende auch in der Zukunft liegen können.
Da wäre es sinnvoll, den Tag nach dem insgesamt spätesten bis-Datum zu nehmen.
Oder den 31.12. aus dem insgesamt spätesten Jahr.

 

Hallo!

Ich nutze auch Null als "offenes Ende" bei Zeitraumangaben.

Meist verwende ich dann eine Bedingung wie:
Code:

mfg
Josef

 

Kleine Betrachtung:
Durch die Verknüpfung mit der Kalendertabelle werden jeweils die Zeiträume in Datensätze mit einzelnen Tagen aufgelöst. Das ergibt erst einmal eine erhebliche Datenmengenvergrößerung.

Viele Daten => viel Arbeit => viel benötigte Zeit
Das kann man sicher unmittelbar nachvollziehen.

Um das Ganze im Rahmen zu halten, darf und sollte man einige Maßnahmen ergreifen:

- Rechtzeitige Datenmengenbegrenzung und -reduzierung. In den oben gezeigten Beispieldaten kommen zwei Kalenderjahre vor. Dazu muss man dann keine Kalendertabelle vorhalten, die 8.000 Jahre mit allen Kalendertagen vorhält.
Auch das mildert das Problem mit dem offenen Ende.

Hast Du überhaupt eine reale Kalendertabelle? Wie sieht die aus?
Vergleiche auch Grundlagen - SQL ist leicht (3) - Kalendertabelle

- Indizierung ist ein MUSS. Siehe auch Grundlagen - SQL ist leicht (8) - Index

 

Ich hab mal ein kleines Beispiel geschnitzt.

Die Prozedur fill_kal() erstellt die Datensätze in T optimal (vom kleinsten bis zum größten Datum aus T1 und T2 - wenn mindestens ein Satz mit Ende offen ist, läuft T bis zum Letzten des Folgemonats des größten Datums.

Die Abfrage AV liefert die IDs aus T1, die vollständig abgedeckt sind.
Die Abfrage AF liefert alle fehlenden Tage.
Die Prozedur fehl_zeit() verdichtet AF zum gewünschten Ergebnis in die Tabelle TF.

 

\@Hans-Christian
Ein wenig abseits: Kannst Du die Indizierung von T1 erklären?

 

Moin Eberhard, so abseits ist das doch nicht ...

Ich hab auf alle drei Felder jeweils einen Index (Duplikate möglich) gelegt.
Den PK habe ich auf die Kombination von 'id' und 'von' gelegt, weil ich davon ausging, dass gleiche Kombinationen von den beiden nicht doppelt vorkommen.
In T2 gibt es aber solche, deshalb habe ich da den PK weggelassen. Nun könnte man ihn freilich auf eine Kombination von allen drei Feldern legen *wink.gif* ... und das in T1 entsprechend ändern ... in TF macht dieser PK aber durchaus Sinn.

/Edit:
Hab gerade bemerkt, dass ich das Schliessen des inneren Recordset vergaß.
Das Fußende von fehl_zeit() muss so aussehen: Code:

Interessant (irritierend) ist, dass es auch ohne .Close funktioniert ...

 

Ich werde mir das alles in ruhe mal anschauen. Jedenfalls gibt die Prozedur das richtige Ergebnis aus.

Vielen Dank bis hier her *Smilie

Jetzt kann ich das schonmal probieren das auf meine verschiedenen Sachverhalte anzuwenden. Zumindest habe ich das Gefühl verstanden zu haben wie hier dabei vorgegangen wird...nur leider reicht das mit meinen derzeitigen Kenntnissen nicht aus so etwas "aus dem Nichts" selber zu erstellen.

Meinen Respekt habt ihr sicher *biggrin.gif* *top

Ich werde ich euch aber bestimmt auch in Zukunft nerven *wink.gif*

 

Das verkneife ich mir regelmäßig. Alles ist möglich, sofern es nicht explizit ausgeschlossen ist.

Damit kann man sich den Extra-Index auf id sparen, der zusammengesetzte Index wirkt "von vorne", also auch beim ersten Feld für sich.