Die DB Anwendung areitet immer langsammer.

[Karstadt]

Eine Frage noch. Wenn ich in eine LOGTABELLE nur reinschreiben. Auswertung dieser Tabelle erfolgt später mit eine andere Anwendung. Um diese Tabelle zu öffnen kann ich doch sagen select * from log where feld ='dierser wert gibt es nicht' dann werden mir keine ds übertragen, ich kann aber in diese Tabelle schreiben richtig?

[mkinzler]

Zitat:

Zitat von Karstadt

Eine Frage noch. Wenn ich in eine LOGTABELLE nur reinschreiben. Auswertung dieser Tabelle erfolgt später mit eine andere Anwendung. Um diese Tabelle zu öffnen kann ich doch sagen select * from log where feld ='dierser wert gibt es nicht' dann werden mir keine ds übertragen, ich kann aber in diese Tabelle schreiben richtig?

Warum ist diese Dummyabfrage den nötig, du kannst doch auch so in die Tabelle schreiben.
Übrigens unterstützt MySQL auch das Limitieren der Ergebnismeneg mit LIMIT.

[Karstadt]

Zitat:

Warum ist diese Dummyabfrage den nötig, du kannst doch auch so in die Tabelle schreiben.
Übrigens unterstützt MySQL auch das Limitieren der Ergebnismeneg mit LIMIT.

Ist das die einzige lösung?

Wie würde die korrekte Abfrage lauten Select * from xyz where Limit = 0

Wenn ich auf Opten gehen dann werden ja alle Ds übertragen.(in diesen Fall open ohne limit)

[mkinzler]

Zitat:

Ist das die einzige lösung?

Wie würde die korrekte Abfrage lauten Select * from xyz where Limit = 0

Nein

SQL-Code:

select * from xyz limit 1

gibt dir nur einen Datensatz aus

SQL-Code:

select * from xyz limit 5,10

die Datensätze 6 - 10
[Edit]sch... Tippfehler[/Edit]

[alzaimar]

Zitat:

Zitat von mkinzler

Zitat:

Zitat von Karstadt

...Wenn ich in eine LOGTABELLE nur reinschreiben. .. Um diese Tabelle zu öffnen kann ich doch sagen select * from log where feld ='dierser wert gibt es nicht' ...

Warum ist diese Dummyabfrage den nötig, du kannst doch auch so in die Tabelle schreiben.

Na ja, direkt mit SQL, ja (also eine UPDATE-Anweisung basteln). Wenn ich nun aber z.B. das Datumsformat nicht kenne (multilinguale Anwendung), wäre es durchaus legitim, eine TQuery so auszustatten:

SQL-Code:

Select * from Table where 1=0

Um die Felder zu beschreiben, kann ich dann die Query öffnen, Append ausführen, und nach dem Posten klappt das dann. Ich habe vor 75 Jahren (ca. :zwinker: ) aufgehört, mit BDE zu arbeiten, also weiss ich gerade nicht, ob es dafür nicht doch ne Komponente gibt. Früher hab ich in der TxLibrary ein TScript gehabt, mit dem man so eine UPDATE-Anweisung basteln konnte...

Grundsätzlich muss man bei der Programmierung zwischen Desktop-Anwendungen und C/S-Anwendungen unterscheiden.

Eine Desktop-Anwendung kann ich ohne Probleme mit Grids und TTables durchprogrammieren, da wird dann ja nix geschaufelt.
Bei einer C/S-Anwendung muss ich diverse Dinge beachten:
- Limitierte Bandbreite bei der Übertragung (also nicht einfach DataSet.Open und ab ins Grid zum Darstellen)
- Kongrutente Bearbeitung von Datensätzen (auch deshalb fällt eine Grid-Darstellung aus, die dann ja per se nicht aktuell ist)
- Der Server gehört keinem Client allein: Also keine rechenaufwändigen Queries durchführen.
- Alle(!) aufwändigen Queries nur über indexierte Spalten laufen lassen. Ansonsten kann es sein, das der Server andere Clients nicht bedienen kann.
...

Und als Grundregel für das Suchen ('Filtern') kann gelten:
Eine Suche ohne Index muss ALLE Datensätze anfassen(!)
Eine Suche mit Index muss nur einen(!) Datensatz anfassen. Über den Index (der als Bayer-Baum implementiert ist) findet man die Recordnummer des gesuchten Datensatz mit maximal 2-5 Festplattenzugriffen (je nach Größe des Indexfeldes). Dann über die Recordnummer gezielt diesen einen Datensatz laden.


Ich stell mir immer vor, meine DB hätte 100.000.000 Datensätze. Zum Testen reichen auch 100.000. Dann sieht man schon, wo die Design- und Indexfehler sind. Ich erstelle mir eigentlich immer eine Test-DB mit entsprechend vielen Einträgen. Damit fall ich dann beim Kunden nicht auf die Schnauze.

[Karstadt]

ich danke euch für Ihre Unterstützung.