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

Aha.
Dann macht es sicher Sinn, in allen drei Tabellen T1, T2 und TF lediglich einen kombinierten PK über alle drei Felder anzulegen, oder?

Das würde mich allerdings schon mal interessieren, ob und wie ... *mrcool

 

Nein, so vereinfacht nicht.
Siehe Mehrfelderindizes richtig planen
Das Gleiche steht auch in meiner "Bibel" (=> verlinktes Dokument in der ersten Zeile meiner Fußnote). Mehrfaches und wiederholtes Lesen lohnt sich!!

Man könnte die Zeiträume gleichlautend wie oben über eine Kalendertabelle in Einzeltage auflösen. Ein Tag, der keinen Vorgänger (Tag - 1) hat, wäre dann der Beginn eines Gesamtzeitraumes. Das Zeitraumende hat dann keinen Nachfolger.

Für die zweite Teilaufgabe (aus einer anderen Aufgabe entnommen):
Code:

 

Hui...ich habe das ganze mal jetzt mit den richtigen Daten gemacht (20000 Kunden IDs in T1 und 150000 Zeiträume in T2. Kalendertabelle wurde von 1988 bis 2017 richtig gefülltt)... jetzt wird die Abfrage leider nicht fertig.

Wahrscheinlich hab ich das mit der Indizierung nicht hinbekommen.

In angehängten Zeiträume.accdb ist die Zeile ID in T1 als Primärschlüssel indiziert ( Dublikate möglich ).

Ich komme noch nichtmal an diesen Punkt bzw. lässt Access dieses nicht zu.

Gibt's da einen Trick?

 

Wo lag das Backend, als du es probiert hast? Ich habe mir gerade noch mal deine Ausgangsfrage durchgelesen und für mich hört sich das was du gerade machst nach einer einmaligen Aufgabe an. Falls dem so ist und falls das Backend gerade noch bei euch irgendwo im Netzwerk liegt, dann zieh dir doch einfach mal eine Kopie vom Backend lokal auf deinen Rechner und probier es so.

Ansonsten darfst du einfach nicht ALLE Daten nehmen, sondern musst sinnvoll portionieren. Mach den Vergleich nicht für alle Kunden auf einmal sondern bspw. für jeden Kunden einzeln (um mal ins Gegenextrem zu fallen).

 

Eine indizierte ID wäre etwas wenig.
Hast Du obige Links bzw. die dahinterliegenden Hinweise gelesen, um zumindest ein Grundverständnis entwickeln zu können?

 

Das mit der Indizierung habe ich schon erfasst (hoffe ich...)

Es ging auch nicht nur um die Zeile ID , sondern mir viel halt beim vergleichen direkt auf das ich diesen Primary Key nicht so gesetzt bekomme wie in der Beispieldatei. Im Nachgang wurde ja auch nochmal erklär weshalb dieser Primary Key so "alleine" gar nicht gesetzt werden müsste.

Für mich ist das natürlich Neuland (und damit schwierig), auch habe ich nicht erwartet das ich bei der Datenmenge Probleme bekomme, zumal alle anderen Berechnungen bzw. Abfragen ohne großen Zeitverlust hinbekommen habe.

Das mit der Partitionierung der einzelnen Dateien werde ich auch mal probieren.

 

Manchmal muss die Vorstellungskraft sprunghaft steigen.
Die Auflösung von Zeiträumen in Tage erhöht ganz sicher die vorhandene Datenmenge.

Auch frage ich mich, welchen ultimativen Tipp Du erwartest, da ja nun keiner DEINE DB mit den aktuellen Tabellenstrukturen und aussagekräftigen Daten und den wirklich verwendeten Abfragen kennt.

 

Hallo an Alle,

erstmal vielen Dank für die ganzen Hilfen. Dadurch war ich jetzt wirklich in der Lage die entsprechenden Daten für mich abzufragen , zumindest erstmal die, welche komplett mit einem Zeitraum aus T2 belegt sind. In der Detailanalyse habe ich 100% Trefferquote an den echten Daten erreichen können (Stichprobe von ca. 50 Kunden). Die Abfrage selbst dauert jetzt ca. 10 Minuten.

Das einzige was ich verändert habe und damit (warum auch immer) einen deutlichen Geschwindigkeitszuwachs bekommen habe war die Abfrage AV in der Datei von Hans-Christian.

aus

SELECT DISTINCT T1.id
FROM T1
WHERE (((T1.id) Not In (SELECT ID FROM AF)));

habe ich

SELECT DISTINCT T1.ID
FROM T1 LEFT JOIN AF ON T1.ID = AF.ID
WHERE (((AF.ID) Is Null));

gemacht.

Leider scheint die Datenmenge zu Groß zu sein um das VBA Script für die Fehlzeiten durchlaufen zu lassen (es stürzt immer ab, bzw. sagt Windows das es keine Rückmeldung mehr gibt. Habe es auch mal ne Stunde laufen lassen aber leider keinen Erfolg).

lg *top

 

Das NOT-IN-Konstrukt verhindert eine Indexnutzung.

Daher sollte es nur für kleine übersichtliche Datenmengen benutzt werden oder alternativ gleich auf den Index gesetzt werden. Es gibt ja Alternativen.

 

Hallo Eberhardt,

vielen Dank für die Erklärung, dass klingt für mich zumindest nachvollziehbar *Smilie

Ich probiere nun auch schon einige Zeit deine eingestellte Abfrage

Code:

auf meine Daten zu überführen, jedoch noch ohne Erfolg. Könntest du diese bitte auf die von Hans-Christian eingestellte Datei abwandeln? Wenn das zu viel Aufwand ist, könntest du mir vielleicht das Ursprungsbeispiel zeigen?

Danke nochmals *Smilie

lg Sebastian

 

Ich hab es mal probiert, aber es gibt eine Parameterabfrage nach T1.t
Datenquelle ist bei mir AF statt 10_tblDatumswerte bei Eberhard
und das Feld heißt bei mir t statt Datumswert bei Eberhard

Die Parameterabfrage kommt auch, wenn ich meine Abfrage entsprechend umbenenne.
Dann wird nach T1.Datumswert gefragt ...

Ich hab den Code aus #32 so kopiert.

Sowas ... das Problem ist, dass es bei mir eine Tabelle namens T1 gibt.
Darüber stolpert Access wohl und lässt diesen Alias nicht zu.
Wenn ich den Alias Tx nenne, klappt es.

Ist allerdings deutlich langsamer als meine Prozedur.
Und setzt - im Gegensatz zu dieser - die Ende-offen-Felder nicht auf NULL.

 

Vielen Dank für die angehängte Datei *Smilie
Ich würde ja gerne die Prozedur von dir nutzen, aber die hängt sich leider auch auf *frown.gif*

Verhindert "WHERE NOT EXISTS " ebenfalls eine Indexnutzung? Die Abfrage läuft jetzt seit über einer Stunde, der Fortschrittsbalken ist fast am Ende und dann leider stehen geblieben *smashing

lg Sebastian

 

An welcher Stelle? Vor dem Abgleich mit T2 oder danach?

Auch ohne Hans-Christians Testversuche: Beide Varianten werden dramatisch Zeit verbrauchen,
1) weil die von mir zitierte Abfrage Schwächen hat
Code:

Berechnung auf Tabellenfeld verhindert Indexnutzung
2) weil die Abfrage von Hans-Christian Schwächen hat
Code:

 

Welche Prozedur hängt sich auf?
Schon die erste, die die Kalender-Tabelle K erstellt? Oder die fehl_zeit()?
Wird denn die Abfrage AF ausgeführt oder hängt sich Access schon dabei auf?

Diesen Ansatz hatte ich ursprünglich auch mal ... habe ihn dann aber wieder verworfen.

Ich hänge mal einen weiteren Versuch an, in dem ich AF verwende um eine Tabelle TAF zu erstellen. Und die Iteration dann auf dieser Tabelle durchführe.

 

Hallo Hans-Christian,

die Abfrage AF wird ausgeführt und auch in entsprechend guter Zeit. Die Kalender-Erstellungs-Prozedur klappt auch. Die fehl_zeit() Prozedur hat nicht geklappt. Ich werde heute Abend mal die neue Datei für meine Daten testen.

Vielen Dank für die Mühe!