> irgendwann bekommst du probleme mit performance. ich w�rde das so Das kann sein...
> machen: > eine temp tabelle aufbauen, > in diese tabelle die schl�sseln reinschreiben, die gepr�ft > werden sollen > (ein insert ist recht schnell) Einer ja.... 2000 inserts sind bestimmt nicht schneller, als 2000 zahlen in einer IN-Klausel > dann pr�fen welche schl�ssel in der basis tabelle vorhanden sind > Ich w�rde das einfach testen... Nichts einfach als das... Erstell Dir einfach eine Tabelle mit entsprechend vielen dummy-Daten und probier mal aus, wie sich die anzahl der ids in der IN-Klausel auf die Performance auswirkt... Ein Problem kann auch noch sein, dass Du langsam an die Grenzen der erlaubten SQL-Statement-L�nge kommst... Das ist z.B. <64kB f�r Access, damit schaffst Du vielleich 10000 bis 15000 IDs, wenn die Performance nicht vorher nachl�sst... Eine andere Frage, die ich mir stelle, ist woher die vielen IDs kommen... 2000 IDs werden bestimmt nicht vom User ausgew�hlt oder eingegeben... D.H. wahrscheinlich sind die IDs schon irgendwo in der DB.. Also wieso l�sst Du sie nicht dort, sondern holst Sie erst raus? Falls Du es nicht weisst, es geht auch sowas: SELECT * FROM daten WHERE id IN (select dataID from IDTable WHERE ...) Claudius | [aspdecoffeehouse] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp
