Geschwindigkeitsproblem

[jbg]

Ich habe da ein kleines aber sehr nervtötendes Geschwindigkeitsproblem.

In einer Liste befinden sich Primarykeys, deren Datensätze bestimmten Kriterien entsprechen (Sowas wie [Tbl1.Feld > 10 und Tbl2.Feld < 10] oder Tbl3.Feld = 10)
Ein JOIN ist in dem Fall nicht möglich, da mehrere Kriterien kombiniert die Ergebnismenge ergeben, wobei diese sich teilweise ausschließen können: (((k1 AND k2) OR k3) AND NOT k4). Das ist alles schon durchgespielt und ich habe mich mit einem Gegenbeispiel überzeugen lassen, dass da kein JOIN möglich ist.
In diesem Primarykey-Ergebnismenge Schritt würde ein Auslesen der Datensätze zu einem rießigen Datenaufkommen führen (weil kein JOIN möglich). Wenn z.B. die das erste Kriterium lautete: Alle Kunden die Älter als 20 Jahre sind, kann das zu 10000 Datensätzen führen. Und da wäre mein momentaner Ansatz um einiges schneller.

Die Aufgabe ist nun die Datensätze für jeden Primarykey aus verschiedenen Tabellen zu hole, um daraus eine ClientDataSet Tabelle zu konstruieren. Mein langsamer Ansatz stellt nun an jede dieser verschienenen Tabellen pro Primarykey eine Prepared SELECT-Anfrage mit WHERE PrimKey='primkey'. Dabei kann eine oder mehrere Zeile herauskommen, die dann zu einer im CDS zusammengefasst werden (Kommaliste). Das ist aber trotz dem Prepared SELECT nicht schnell und kann bei vielen Primarykeys schon Richtung 1 Stunde gehen.

Eine Überlege von mir ist, mehrere Primkeys-Anfragen zu einer einzigen zusammenzufassen ala

Code:

SELECT field1, field2, ... from table1 WHERE PrimKey='primkey1' OR PrimKey='primkey2' OR ...

Nur gibt es da ein kleines Problem. Da macht Oracle nicht wirklich mit. Zum einen gerate ich an einen Bug von i9, bei dem die DB abfängt zu arbeiten und nicht mehr aufhört, obwohl das Ergebnis nur 2 Einträge liefern sollte. Und zum anderen kann ich das nicht für 10000 Primarykeys auf einmal machen. Wobei man das durch geschicktes Verteilen bereinigen kann (z.B. 10 Primkeys auf einmal). Aber der i9 Bug ist da das größte Problem. Leider kann ich den Bug im Moment nicht reproduzieren, weil sich die Tabellen mittlerweile geändert haben. Aber mit der Ungewissheit, dass er eintreten kann, kann man das fertige Produkt nicht auf den Kunden loslassen.

Irgendwelche Vorschäge, andere Ansätze?