Und hier das Posting nicht abgeschnitten

[Michael Schröpl]

Hi Moses,

Im prinzip müßte ich also wie folgt vorgehen (mal ganz vereinfacht geschrieben):

nein, das wäre in der Tat viel zu teuer.

Berechne beide Mengen nacheinander und lasse sie jeweils nach Personen_ID sortieren.

Anschließend kannst Du eine Schleife über die erste Menge laufen lassen und jeweils vergleichen, ob das aktuelle Element mit dem _ersten_ bisher gelesenen Element der zweiten Menge übereinstimmt.
Ist es kleiner, dann gehört es zu Deiner Ergebnismenge; ist es gleich, dann verwirf es und lies das nächste Element für _beide_ Mengen ...

Der Trick dabei ist, daß dies genau dann funktioniert, wenn beide "Mengen" eben als sortierte Listen vorliegen. Stell Dir vor, Du mischst zwei sortierte Folgen zusammen, indem Du mit zwei Tonköpfen über zwei Bänder fährst (deshalb Zwei-Bänder-Mischen) - hier tust Du fast dasselbe, Du wertest die Erkenntnisse nur anders aus.

Außerdem suche ich ja dadurch über die größere Menge (es gibt mehr Personen die mindestens einem Ereignis zugeordnet wurden, als Personen die keinem Ereignis zugeordnet wurden.)

Das ist nicht zu vermeiden, weil Deine Differenzmenge durch Dein Datenmodell nicht in anderer Art und Weise definiert ist.

Wenn das eine _häufige_ Operation in Deinem Universum sein sollte, könntest Du jeder Person ein "Nicht-Ereignis" geben. (Als zusätzliche Spalte in der Personen-Tabelle!)
Du müßtest dann allerdings bei sämtlichen Einfüge- und Lösch-Operationen für Ereignisse dieses "Flag" konsistent pflegen. Dies wäre sehr fehleranfällig in der Programmierung (Trigger/Stored Procedures wären hier hilfreich!), und es ist natürlich ein ästhetischer Bruch im Datenmodell - aber es wäre für diese hochspezialisierte Anwendung ein riesiger Performance-Gewinn erzielbar ... (auch gegenüber MINUS, was sich ja algorithmisch von der obigen 3GL-Lösung kaum unterscheidet)

Man muß halt wissen, an welchen Stellen es sich lohnt, gegen den "guten Geschmack" zu verstoßen.

Viele Grüße
      Michael