AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi Die DB Anwendung areitet immer langsammer.

Die DB Anwendung areitet immer langsammer.

Ein Thema von Karstadt · begonnen am 17. Feb 2006 · letzter Beitrag vom 20. Feb 2006
Antwort Antwort
Seite 2 von 2     12
Karstadt

Registriert seit: 8. Nov 2005
788 Beiträge
 
#11

Re: Die DB Anwendung areitet immer langsammer.

  Alt 17. Feb 2006, 21:56
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?
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.859 Beiträge
 
Delphi 11 Alexandria
 
#12

Re: Die DB Anwendung areitet immer langsammer.

  Alt 17. Feb 2006, 22:09
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.
Markus Kinzler
  Mit Zitat antworten Zitat
Karstadt

Registriert seit: 8. Nov 2005
788 Beiträge
 
#13

Re: Die DB Anwendung areitet immer langsammer.

  Alt 19. Feb 2006, 00:48
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)
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.859 Beiträge
 
Delphi 11 Alexandria
 
#14

Re: Die DB Anwendung areitet immer langsammer.

  Alt 19. Feb 2006, 09:28
Zitat:
Ist das die einzige lösung?

Wie würde die korrekte Abfrage lauten Select * from xyz where Limit = 0
Nein
select * from xyz limit 1 gibt dir nur einen Datensatz aus
select * from xyz limit 5,10 die Datensätze 6 - 10
[Edit]sch... Tippfehler[/Edit]
Markus Kinzler
  Mit Zitat antworten Zitat
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
Karstadt

Registriert seit: 8. Nov 2005
788 Beiträge
 
#16

Re: Die DB Anwendung areitet immer langsammer.

  Alt 20. Feb 2006, 08:49
ich danke euch für Ihre Unterstützung.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:07 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz