Einzelnen Beitrag anzeigen

alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#15

Re: Die DB Anwendung areitet immer langsammer.

  Alt 19. Feb 2006, 09:33
Zitat von mkinzler:
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:
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. ) 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.
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat