Das Problem ist, es wird teils relativ oft ausgeführt also jede Minute sowas ...
Ich werde es in diesem Fall dann zu dem jeweiligen User die letzte ID speichern, dann gehts natürlich extrem schnell.
Nichts für ungut, aber daß jede Minute sich jemand für die letzte Buchung von 800 Benutzern interessiert, halte ich für Blödsinn. Daß irgendjemand sich für die letzte Buchung eines Benutzers oder einer Benutzergruppe interessiert, das glaube ich schon schon eher.
Gruß
K-H
das stimmt schon direkt nicht aber indirekt, es wird halt zyklisch der status der 800 user geladen, und diese dann gruppiert auf abteilungen dargestellt, wobei man mit incrementalsearch dann sehr schnell zum status des einzelnen users kommen kann.
Da ja auch paar andere infos geladen werden.
Kann man sicher auch besser machen und anders optimieren, aber eben der extremst große und bis jetzt unbekannte zeitfaktor war eben das FireBird beim GroupBy keinen Index verwenden kann.
Und die 800.000 Datensätze in ein paar Jahre dann 8.000.000 werden usw.
Aber es wurde ja schon ein WorkAround genanntm zumindest solange bis FireBird das hoffentlich irgendwann mal optimieren kann
