Die DB Anwendung areitet immer langsammer.

[Karstadt]

Hallo. Habe folgendes Problem. Eine DB Anwendung. Produziert jeden Tag ca 50 DS. Die DS werde nie gelöscht. Nun bin ich bei den DS 3000. Die Anwendung arbeitets spürsam langsammer. Woran kann das liegen?

Diese Anwendung greift über BDE->ODBC->MYSQL auf MYSLAM Tabelle zu. Im hintergrund sind 3 Timer.

Danke für ihre Hilfe.

[Boombuler]

Wobei arbeitet die Anwendung denn langsamer? Schreiben / Lesen in / aus der DB oder allgemein?
Ich benutz die BDE zwar nich sondern DBX aber evtl solltest du mal nachsehen ob der evtl. versucht alle Datensätze gleichzeitig zu lesen. Das würde extrem viel Speicher benötigen und dem entsprechend wäre das Programm auch langsamer...

Greetz
Boombuler

[Jasocul]

Du hast also mindestens zwei Bremsen drin: BDE und ODBC. Obwohl das mit ODBC nicht mehr so schlimm sein soll.
Wird in den Timern auf die DB zugegriffen?
Greift nur einer zu?
Hast du einen Primary-Key?
Benutzt du Indexe?

Das müsste erstmal geklärt werden.

[Karstadt]

Timer gibt die Zeit aus. Und liest ein DS aus der Tabelle MA. (in diese Tabelle sind das insgesammt)10 DS.

Der anderer Timer liest datensätze aus einen aderer Tabelle.

TTimer ist auf 1000 eingestellt. (ohne Timer bringt das zwar etwas, aber nicht viel!)

Greift nur einer zu?
-JA
Hast du einen Primary-Key?
-JA
Benutzt du Indexe?
-Nein (gibt es bei MYSQL indexe)

Hat das vielleicht damit zutun, das die DB MYSQL ENGINE MYSLAM ist?

[Elvis]

Zitat:

Zitat von Karstadt

Benutzt du Indexe?
-Nein (gibt es bei MYSQL indexe)

Und schon haben wir dein Problem.
Mit Indizes hast du Suchzeiten von log(b, n), wobei b von der Tabellengröße abhängig ist und zwischen 2-40 betragen wird.
Es ist also durchaus nicht ungewöhnlich, dass du um einen Datensatz aus 10^6 Datensätzen abzufragen nur 5-10 Vergleiche nötig sind. ;)
Ohne Indizes wären es ein paar Tausend mehr. :mrgreen:

Mit Indizes wachsen die Suchzeiten also nur minimal mit der Tabellengröße an. Dafür werden Datenänderungen auf die indizierten Felder/Löschungen/Einfügen aufwendiger (Der Index muss neu aufgebaut werden).

Du musst also abwägen aus Abfragegeschwindigkeit und Einfügegeschwindigkeit....

[Karstadt]

Meine Frage ist. Wie kann ich bei MYSQL mit INDEXEN arbeiten. Bis jetzt habe ich gedacht, das die MYSQL Ohne Indexe auskommt, weil die Anrfage wie z.B. Sorted By *** ASC oder Where Field = True. Die Datenmenge schon einschrenkt.

Bei DBASE IV war eine extra indexdatei dafür gedacht, aber bei MYSQL ? Wo kann ich mich schlau machen?

So sieht übringes eine Tabelle von mir aus.

[Phistev]

Indizes schränken die Datenmenge nicht direkt ein, sie helfen nur, wenn die Datenmenge per WHERE eingeschränkt wird. SORTED BY schränkt auch nicht ein, sondern sortiert nur. Um einen Index zu erstellen nutze

SQL-Code:

ALTER TABLE `tabelle` ADD INDEX (`name_der_spalte`)

Und, wenn's geht, nutze die zeoslib statt ODBC & BDE.

[Bernhard Geyer]

Zitat:

Zitat von Karstadt

Meine Frage ist. Wie kann ich bei MYSQL mit INDEXEN arbeiten. Bis jetzt habe ich gedacht, das die MYSQL Ohne Indexe auskommt, weil die Anrfage wie z.B. Sorted By *** ASC oder Where Field = True. Die Datenmenge schon einschrenkt.

Der Index beschleunigt nur die bestimmung der Ergebnismenge. Aber das MySQL keine serverseitigen Curser hat werden alle Datensätze beim Öffnen der Query sofort an den Client übertragen. Und schätz mal wieviel Bytes bei 3000 Datensätzen übers Netz geschaufelt werden müssen.

[Jelly]

Prinzipiell sollte immer sollte IMMER vermieden werden, 3000 Datensätze zum Client zu schippen. It nicht nur langsam, sondern zudem wird kein Mensch diese 3000 Datensätze durchwühlen, um was zu suchen. Für solche Zwecke lässt Du den Anwender Filter setzen, die Du dann geeignet in deiner SQL Abfrage einbaust.

Frage: Überträgst Du alle Datensaätze. Wenn nein, wie filterst Du. Ich hoffe nicht mit der "Filter" Eigenschaft deines Datasets.

Und noch was, was ich nicht verstehe: Du hast mittlerweilen schon etliche Threads eröffnet, wo Du nach Alternativen zu BDE fragst, und scheinst dich ja mittlerweilen für die MyDAC Komponenten zu begeistern. Kannst Du mir erklären, warum Du denn in diesem Fall die BDE trotzdem nutzt. Macht doch keinen Sinn.

Noch was Entscheidendes: Wo liegt die Datenbank? Lokal (bzw. im LAN) oder im Internet?

[Karstadt]

Hallo.

Zitat:

Frage: Überträgst Du alle Datensaätze. Wenn nein, wie filterst Du. Ich hoffe nicht mit der "Filter" Eigenschaft deines Datasets

Nein in diesen Fall würde auch alle DS übertragen! Filtrierten DS werden angezeigt andere ausgeblendet.

Zitat:

Und noch was, was ich nicht verstehe: Du hast mittlerweilen schon etliche Threads eröffnet, wo Du nach Alternativen zu BDE fragst, und scheinst dich ja mittlerweilen für die MyDAC Komponenten zu begeistern. Kannst Du mir erklären, warum Du denn in diesem Fall die BDE trotzdem nutzt. Macht doch keinen Sinn.

Noch was Entscheidendes: Wo liegt die Datenbank? Lokal (bzw. im LAN) oder im Internet?

Das ist ein bestehender Projekt der vor Monaten MIT Bde Komponenten programmiert wurden. Alle neue Projekte programmiere ich mit der neue Komponente.

Die DB liegt lokal! Die wir mit Select * from xxx aufgerufen ohne where (das ist bestimmt ein fehler!)

es werden neue "buchungssätze" als offen hinzugefügt. Interessant ist nur diese DS. Wenn ein Auftrag ferti ist wird eine Feld auf "Fertig" gesetzt. In meinen Fall kann ich die erledigten aufträge ausblenden (das sind ca 2000!).

Danke, das werde ich ausprobieren!

An einigen Stellen arbeite ich mit Locate und Loockup. Soll ich das auf SQL umstellen?

[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.