Ein Riesen-Join oder eine Handvoll kleine Züge?

[Rolf b]

Die correlated Subquery ändert aber nichts an dem Umstand, dass sie für jede einzelne Ameise und vor allem Fliege den Namen des zugehörigen Wärters in der Ergebnismenge hat.

Damit eine historische Query funktioniert, brauchst Du historisierte Tabellen. Wärter Nr 5 darf nicht am Montag der Klaus und am Mittwoch die Claudia sein (es sei denn, er war am Dienstag beim Chirurgen). Wenn das Ameisengehege am Dienstag die ID 7 hat und am Donnerstag die ID 9 (weil die Tierchen am Mittwoch umgezogen sind), kann eine retrospektive Auswertung merkwürdig aussehen, wenn Du auf einmal 5000 Elefanten im Ameisengehege mit bestem Aas-Granulat fütterst (die Fliegen-Nahrung).

Da die Sterblichkeit der Wärter sicherlich gering ist und die Gehege vermutlich auch nicht so oft ihren Platz wechseln, KÖNNTEST Du in zwei vorauslaufenden Abfragen erstmal alle relevanten (sprich: historisch für den Auswertezeitraum gültigen) Wärter und Gehege in Arbeitstabellen deines Auswerteprogramms laden. Und dann machst Du einen Join auf Tiere und Fütterungen, um die Fütterung jeder einzelnen Ameise und Fliege zu bekommen. Bei den Tieren findest Du die Gehege-ID, bei den Fütterungen die Wärter-ID desjenigen, der gefüttert hat, und suchst Dir den historisch richtigen Satz aus den vorgeladenene Tabellen dazu. Für die Ausgabe kannst Du dann z.B. nach Tierart gruppieren, die Tierart als Überschrift ausgeben, darin die Tiere und für die Tiere eine Unterzeile pro Fütterung. In die Fütterungen kannst Du an Hand der ID den Namen des Wärters einstreuen.

De facto wirst Du sicherlich was anderes tun wollen, aber von der Idee her kann das so gehen.

Wenn Du Sorge hast, dass sich Tabellen während des großen Join ändern, brauchst Du eine Transaktion um das Ganze mit einem entsprechenden Isolationslevel. Siehe Datenbankhandbuch...

Rolf