Bin mir nicht sicher, aber meine Vermutung ist, dass einfach die Menge der (eventuell sogar gleichzeitig) auf die Datenbank losgelassenen Abfragen, einfach die (Verbindungs-?)Kapazität zwischen Client und Datenbank übersteigt.
Schau bitte mal, ob es da technisch oder konfigurationsbedingt, irgendwelche Einschränkungen gibt.
Nehmen wir mal die Felgengröße als konkretes Problem:
Es können, für die vier Felgengrößen, zu beliebigen Zeiten, beliebig viele Änderungen eingepflegt werden.
Des weiteren gehen wir davon aus, dass Du Dich für die oben skizzierte "Feld"-Tabelle für die Felgengrößen entschieden hast.
Um diese Feldtabelle nun mit wenig Aufwand zu pflegen, könnte eventuell ein Datenbanktrigger für ein Insert in die Tabelle Reifenlager reichen.
Dieser Trigger wird immer dann von der Datenbank automatisch ausgeführt, wenn ein neuer Datensatz in die Tabelle Reifenlager eingefügt wird.
Innerhalb dieses Triggers müsste dann geprüft werden, ob es die Felgengrößen schon in der Feldtabelle gibt, wenn nicht, wird ein neuer Datensatz eingefügt.
Wenn aus dem Reifenlager ein Datensatz entfernt wird, so muss ein Trigger für das Ereignis Delete ausgeführt werden.
Dieser Trigger muss dann aus der Feldtabelle alle die Felgengrößen entfernen, die es nun in der Tabelle Reifenlager nicht mehr gibt.
Für Änderungen im Reifenlager muss es einen Trigger für das Ereignis Update geben. Hier ist dann zu prüfen, ob es alle Felgengrößen dieses Datensatzes schon in der Feldtabelle gibt, wenn nein, müssen sie hinzugefügt werden. Die Felgengrößen, die es nicht mehr gibt, müssen entfernt werden.
Ob das für die Datenbank dann weniger Arbeit ist und insgesamt schneller wird, als Deine bsher angedachte Lösung, vermag ich nicht zu sagen. Hier müsstest Du mal probieren, ob Du das mit My-
SQL (da fehlt mir leider jegliche Erfahrung) realisieren kannst. Bei Oracle wüßte ich, wie ich vorgehen könnte, weiß aber nicht, ob und wie das auf andere Datenbanken übertragbar ist.
Zitat:
Gut, das könnte sein. Aber das Order by wird dann ja auch nicht mehr großartig Last verursachen, da ja schon alles 'sortiert' ist.
Naja, zumindest von Oracle kenne ich das so:
Zuerst wird das innere
SQL ausgeführt, also die Unions un das Ergebnis wird sortiert. Es muss also temporär vorgehalten werden.
Anschließend wird das äußere
SQL über die temporär vorgehaltenen Ergebnismenge ausgeführt und sortiert.
Ob und wieviel Last bei 'ner kleinen DAtenmenge dabei entsteht, mag ich nicht zu beurteilen.
Fakt ist, es ist überflüssig und sollte damit entfallen.
Auch viele, kleine, überflüssige, nur wenige resourcenverbrauchende, Abfragen erzeugen zusätzliche Laufzeit.
Und wenn mir ein System zu langsam ist, dann spare ich grundsätzlich alles ein, was Laufzeit kostet, auch wenn es (dem ersten Augenschein nach) nur auf die einzelne Abfrage sehr wenig ist.
Zitat:
Das wäre natürlich dann kein wirklicher Vorteil. Ist zwar schön, dass man sich dann etwas Schreibarbeit spart, aber wo ist der effektive Vorteil?
Naja, stell' Dir mal ein sehr komplexes System vor, in dem so ein Statement nicht mal eben in vier Zeilen "abzufackeln" ist, sondern eher mal ein paar hundert Zeilen lang wird.
Und nun wird dieses Statement nicht nur an einer Stelle benötigt, sondern an vielen, z. B. in einer Desktop-App, einem Webinterface, für den Reportgenerator ...
Nun muss man dieses Teil schon an drei Stellen pflegen. Mit 'ner View aber nur noch einmal.
Mal flappsig und überspitzt formuliert:
Alles was ich in Delphi mehr als einmal benötige wird zu 'ner Funktion oder Prozedure.
Jedes Select-Statement, das ich mehr als einmal benötige, wird zu 'ner View.
Ansonsten zur Fehlermeldung:
Schau bitte mal hier:
https://www.benefind.de/web.php?q=%2...+mysql&org=307
Es scheint dort mehrere Lösungsansätze zu geben.