Selektierte Datenätze in neue Abfrage

[Sir Rufo]

Am elegantesten geht es, wenn du eine temp. Tabelle anlegst und bei jedem Auswählen eines Datensatzes diesen in die temp. Tab einfügst bzw. auch wieder löschst (nur den PK)

Das ist für den User gefühlt die schnellste Art

[TKanne]

Hmm, das mit der Temp-Tabelle wäre evtl. auch eine Variante, allerdings in diesem Fall ungünstig, da ich nur zu Auswertungen auf eine 'fremde' Datenbank zugreife und dort nur Leserechte habe.

[jobo]

Ich würde mich allen anschließen.

Code:

where [] in (...)

ist sicher eine einfache und preiswerte Möglichkeit.

Code:

[temptable]

bietet sich vor allem wegen der Performance an. Das hängt aber auch stark mit den erreichbaren Ausführungsplänen und Mengengerüsten zusammen. Weiß nicht, was der mySQL Optimizer alles kann.
Es muss nicht mal unbedingt "temp" sein. Eine permanente, userspezifische Tabelle könnte nicht nur die gewünschten Subselects liefern, sondern bspw. die letzten 10 Selektionen speichern....

P.S.: nur Leserechte passen natürlich eher zur ersten Variante

[TKanne]

Hallo,

danke für Eure Vorschläge.

So, ich habe es jetzt mit der

Code:

where [] in (...)

Variante gemacht.

Funktioniert erst einmal soweit, zumindest mit 1342 selektierten Datensätzen, und die Select-Zeit ist auch akzeptabel, zumindest wenn man temporär das Dataset auf DisableControls setzt.
Allerdings bin ich mir noch etwas unsicher, das es ab einer gewissen Anzahl evtl. zu Problemen kommen kann.

Das war ja im Prinzip auch mein Ansatz, hatte nur gedacht, das wäre etwas laienhaft und es gäbe eine elegantere Lösung.

Aber die Temp-Tabellen-Version bzw. das speichern der Selektion in einer speziellen Tabelle werde ich mir mal für ein anderes Projekt merken.

Also Vielen Dank erst einmal,
TKanne

[jobo]

Zu "where.. in.." sollte es je nach DB Version Limits geben (Doku, ..).
Welcher normale Benutzer selektiert aber per Klick mehr als 1000 Sätze?
Hier würde ich notfalls in der Anwendung ein Limit setzen oder auch in der Benutzerunterstützung. "select all" dürfte es dann nicht geben.

[Jumpy]

Eine andere Methode, die ich mal bei einer Access-DB angewendet habe. Da hatte die Tabelle eine weitere (im normalen Verlauf nicht genutzte und nicht sichtbare) Spalte, die einen Boolean-Wert oder 0/1 hatte. Da wurde dann einfach beim Selecten, oder Doppelklicken der Datansatz von 0 auf 1 geändert oder umgekehrt.

Dann braucht die ursprüngliche Query nicht nach ausgewählten Elementen durchgeeiert zu werden, und auch kein langes "in (..)" oder "..or..or..or.." SQL-Statement, sondern nur der Select auf True oder 1 (in dieser Spalte) eingeschränkt zu werden.

Keine Ahnung ob das eine sonst sinnvolle Lösung ist, der DB eine Spalte mitzugeben, die nicht wirklich Daten enthält, sondern nur der bequemen Steuerung dient. Dazu hab ich noch zu wenig Erfahrung und bin kein Datenbankler.

OT: Wieso heißt es eigentlich Datenbankler und nicht Datenbanker?

[Sir Rufo]

Das ist aber auch nur dann sinnvoll beim Single-User Betrieb.
Sobald mehrere gleichzeitig mit den Daten arbeiten geht das nicht mehr.

Aber er hat nur einen rein lesenden Zugriff auf die Daten

[Jumpy]

Zitat von Sir Rufo:

Das ist aber auch nur dann sinnvoll beim Single-User Betrieb.
Sobald mehrere gleichzeitig mit den Daten arbeiten geht das nicht mehr.

Stimmt. Daran hab ich gar nicht gedacht.

Zitat von Sir Rufo:

Aber er hat nur einen rein lesenden Zugriff auf die Daten

Und das hab ich gepflegt überlesen.