Nur erstmal so ein paar hingeworfenen "Gedankensplitter"
Selects, die per Union zusammengefügt werden, werden zur Dublettenbeseitigung von der Datenbank sortiert. Das Order by kann daher eigentlich entfallen, es wäre zumindest schon mal eine "Optimierungsmöglichkeit".
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.
Wie oft werden die Felgengrößen verändert, ergänzt ...?
Eher sporadisch?
Das ist je nach Jahreszeit unterschiedlich.
Dann erstelle Dir eine Tabelle in der Form:
Code:
create tbl_Felgengroessen as
select s_vl_felgengroesse as Feld from Reifenlager t1 union
select s_vr_felgengroesse as Feld from Reifenlager t1 union
select s_hr_felgengroesse as Feld from Reifenlager t1 union
select s_hl_felgengroesse as Feld from Reifenlager t1) t21
(Eventuell ist bei Deiner Datenbank die Syntax etwas anders, bitte ausprobieren)
Die Tabelle bindest Du dann überall dort ein, wo Du bisher Deine Union-Abfrage nutzt. Das dürfte den Aufwand, den die Datenbank betreiben muss, etwas reduzieren.
Das könnte ich natürlich auch machen. Aber diese Tabelle müsste ja auch immer wieder auf den aktuellen Stand gebracht werden. Das wollte ich ja im Grunde mit der View erreichen.
Du musst halt sicherstellen, dass diese Tabelle immer dann neu erstellt wird, wenn es bei den Felgengrößen eine Änderung gab.
Ob zur Laufzeit nun Dein Select ausgeführt wird oder die (momentan) nicht erstellbare View, dürfte egal sein. Bei einer Abfrage auf die View muss die Datenbank ja das dahinterliegende Select ausführen.
Das ist vielleicht mein Denkfehler. Ich habe Views noch nie genutzt. Ich hatte gedacht das ein View vom
SQL-Server immer dann aktualisiert wird, wenn sich an den Referenztabellen Daten verändern. Quasi auf Verdacht, so dass die Daten im View bei Bedarf bereit fix und fertig zur Verfügung stehen, und nicht erst erzeugt werden müssen, wenn die Abfrage kommt.
Eventuell lässt sich die View so erstellen:
Code:
create view v_Reifengroessen as
select s_vl_felgengroesse as Feld from Reifenlager
union
select s_vr_felgengroesse as Feld from Reifenlager
union
select s_hr_felgengroesse as Feld from Reifenlager
union
select s_hl_felgengroesse as Feld from Reifenlager
Spitz formuliert ist die View ja nur eine "Schreibvereinfachung" für ein mehr oder weniger komplexes
SQL-Statement.
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?
Die Idee von EarlyBird mit zwei View ist ganz nett, aber ein
Code:
Select Feld from test1 order by feld
unterscheiden sich wohl weder im Aufwand noch im Ergebnis von
Code:
Select Feld from test2 order by feld
Oder: Die zweite View ist meiner Meinung nach entbehrlich.
Das werde ich mal ausprobieren.
Auch wenn die Datenmenge von 850 Sätzen jetzt nicht wirklich nach sehr viel aussieht, so dürfte die Häufigkeit der Abfragen die Datenbank doch schon etwas ans Schwitzen bringen.
Deswegen bekomme ich wahrscheinlich auch das "Lost Connection during
Query". Obwohl die Abfrage trotzdem gefühlt nur 1 oder 2 Sekunden dauert. Es wundert mich doch schon.
In welcher Form benötigst Du die Ergebnisse dieser Abfragen im Programm?
Als Nachschlagtabellen, Inhalte von Listboxen ...?
Eventuell reicht es ja aus, wenn Du die Abfragen nur beim Programmstart lädst und dann innerhalb des Programmes in Listen bereithälst.
Genau. Ich brauch sie für eine Combobox, für die Auswahl durch den User.
Ich könnte sie natürlich bei Programmstart laden. Da die Anwendung aber den ganzen Tag am Stück läuft, würden sich die Einträge nicht mehr aktualisieren. Und bei 10 Benutzern, würde das gerade in den Jahreszeiten wo sich genau diese Daten stark verändern dazu führen, dass der eigentliche Nutzen nicht mehr so unbedingt gegeben ist. Wenn ein neues Element hinzugekommen ist, soll diese am gleichen aber auch an anderen Arbeitsplätzen gleich zur Verfügung stehen. Schon allein um unterschiedliche Schreibweisen möglichst zu vermeiden.
Außerdem ändert das ja nichts an dem Problem. Dann würde im schlimmsten Fall die Fehlermeldung gleich zu Beginn kommen.
Und gerade weil diese Abfrage ja ein wenig länger braucht, als ein einfaches Select habe ich das in ein Thread gepackt.
Wenn im dem nur eine diese Abfragen laufen würde, wäre es vielleicht auch noch kein Problem, aber ich muss das für 10 verschiedenen Felder machen. Und zwischen den Abfragen innerhalb des Thread noch Sleeps einzufügen würde dessen Laufzeit auch wieder unnötig verlängern.
Wenn alle Stricke reißen, dann müsste ich halt die per union verknüpften Abfragen im Thread einzeln machen und dort zusammensetzen.
Mich wundert aber trotzdem, dass der Fehler "Lost Connection during
Query" auftritt. Er kommt definitiv nur wenn ich die
Query mit Union ausführen lasse. Lasse ich die Weg, habe ich kein Problem mehr. Nach allem was ich gelesen habe, kommt diese Fehlermeldung aber nicht vom Zeos selbst, sondern von der libmySQL50.dll und wird von Zeos nur weitergereicht. Von daher kann ich daran programmmäßig auch nicht wirklich viel ändern. Ein Timeout einstellen kann ich meines Wissens nicht. Außer vielleicht in der my.cnf.