Komplizierte SQL-Abfrage
-
@SideWinder: Welche können es denn nicht? Mir fällt so spontan nur MySQL ein, aber seit Version 4 (?) sollte auch MySQL das können.
@dEUs: Gerne geschehen. Was hast Du denn für eien DB? Schon ausprobiert, ob Subselects funktionieren?
-
Es ist eine Access- und eine MySQL-Datenbank. Getestet habe ich es noch nicht.
-
..und wenn nicht dann mach daraus 2 oder mehr selects. ich glaub' keiner zwingt dich alles in ein sql statement zu packen.
-
@dEU wegen deinen doppelten Posts: FROM tabelle1,tabelle2, da bekommst du das Kreuzprodukt der beiden Tabellen. DAher so viele Einträge. Dadurch musst natürlich im WHERE-Teil das wieder rausfiltern oder evtl sogar einen andern JOIN benutzen.
-
Jo, das ist klar.
Ich weiß immer noch nciht, ob der Subselect tut, weil ich ihn nciht getestet habe. Die Abfrage die ich durchführen musste wurde immer komplexer, ich wusste nicht, ob das überhaupt mit SQL geht und hab nen Teil jetzt in C++-Code ausgelagert
-
Der User-Name, wieviele Disziplinen er insgesamt absolviert hat und wieviele davon den Kriterien entsprechen.
Bei genauerem Nachdenken kann das gar nicht mit einem SQL-Statement gehen. Immerhin willst du auf verschiedenen Grundmengen count() ausführen. Das ist afaik nicht drin.
MfG SideWinder
-
zur Not Variablen anlegen und das ganze in mehrere SELECTs aufteilen
-
Wie gesagt, ich habe jetzt einen Hybriden aus 2 SQL-Abfragen und C++-Code gebastelt. Danke für eure Hilfe
-
Ich bin trotzdem der Meinung, dass man dieses Problem in reinem SQL hätte lösen können. Notfalls mit Mehrfachselects auf die gleiche Tabelle und entsprechenden einschränkenden Subselects. Bei größeren Tabellen ist eine solche Vorgehensweise allerding sehr Performancefressend.
-
Möglicherweise. Aber ich hatte ehrlich gesagt nciht den Nerv mich da so tief reinzuarbeiten
-
Joe_M. schrieb:
Ich bin trotzdem der Meinung, dass man dieses Problem in reinem SQL hätte lösen können. Notfalls mit Mehrfachselects auf die gleiche Tabelle und entsprechenden einschränkenden Subselects. Bei größeren Tabellen ist eine solche Vorgehensweise allerding sehr Performancefressend.
Imho aber immer noch schneller auf der DB als die Implementierung in C-Code.
MfG SideWinder
-
in reinem sql geht es vielleicht als 'stored procedure'. da hat man auch kontrollstrukturen wie if/then/else usw.
-
net schrieb:
in reinem sql geht es vielleicht als 'stored procedure'. da hat man auch kontrollstrukturen wie if/then/else usw.
dEUs hat bereits die Zieldatenbanken (sofern sich diese Datenbanken nennen dürfen) gepostet, mit denen kann man keine ordentlichen Stored Procedures erstellen.
MfG SideWinder