|
| |
Allgemeine Diskussionen| Re: Daten filtern vs Daten abfragen | |  | | Autor: Franki | | Datum: 19.01.17 03:35 |
| Hallo Manfred X
| Zitat: | |
Du scheinst bei DB-Abfragen die Alternative entweder
alle Daten oder sehr stark selektives Filtern anzunehmen.
| |
Genau so ist es, wenn ich z.B. nach Rechnungsnummer 4711 oder Artikelnummer 0815 abfragen möchte, dann brauche ich nur genau diesen einen Datensatz (falls er denn existiert)
| Zitat: | |
So stellt sich das Problem nicht.
In ADO.Net wird eine Verbindung geöffnet, eine benötigte Menge
Daten abgefragt und die Verbindung wird - bis zum Update oder
bis zur nächsten Abfrage - wieder geschlossen.
Bei der Gestaltung der Abfragen muß man Überlegungen zu
einer Gesamt-Optimierung anstellen.
| |
Soweit so gut, aber die "benötigte Menge" steht ja meistens schon fest bevor die Datenbank abgefragt wird. Also wie oben, Rechnungs- oder Artikelnummer.
Und selbst wenn ich z.B. nach PLZ-Bereichen abfragen möchte steht zwar die Menge nicht fest, aber das Kriterium.
Mir ging es bei bei meiner Frage darum, dass z.B. alle Kunden erst eingelesen werden, dann nach dem PLZ-Bereich gefiltert werden und dann das Ergebnis für den User angezeigt wird.
| Zitat: | |
Es ist auch zu bedenken, daß man bei vielen Anwendungsfällen
in Datenbanken integrierte Methoden hinterlegen kann, die Daten
bereits intern prüfen/filtern/aufbereiten/stat. Kennwerte bestimmen
usw. so daß die zu übertragende Datenmenge stark reduziert wird.
| |
Genau, also eine SP sozusagen der nur die Parameter übergeben werden, die DB regelt das dann intern und liefert nur die entsprechenden Datensätze zurück, die Rechenleistung usw. passiert auf dem Recher/Server wo die DB liegt.
| Zitat: | |
4. Ausführung der Abfrage, die eine Anzahl von Sätzen
überträgt,
die dieser Zielgröße am nächsten kommt.
| |
Und auch das ist schon seit Jahrzehnten üblich, gab es in Form Paging schon in ADO Classic.
Was du da beschreibst ist eigentlich das wass ich schon immer in der Praxis mache. Mich hat nur gewundert, dass es in letzer Zeit viele Beispiele hier und anderswo gibt die zuerst alle Daten einlesen und danach erst filtern was gebraucht wird.
Natürlich hat eine nachträgliche Filterung auch ihre Berechtigung, die nutze ich auch schon immer. Aber wie du schreibst, es kommt halt immer auf den Einzelfall an bzw. die Datenmenge usw.
Ich werde bei meiner Verfahrensweise bleiben weil ich (und meine Kunden) halt oft schlechte Performande hier in der Provinz habe wenn die Datenbanken nur übers Internet (ASP, ASP.NET, PHP usw. erreichbar sind) Da kommt es bei großen Datenmengen zwar nicht früher auf jedes Byte an, aber die Performance ist schon ein Thema was nicht zu vernachlässigen ist.
Unser "Digitalminister" wie ich ihn oft nenne redet zwar viel, aber hier tut sich noch nicht wirklich was in Sachen Breitbandausbau. Und selbst wenn, ist das Thema Performance damit ja nicht vom Tisch.
Gruß
Frank | |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
sevGraph (VB/VBA) 
Grafische Auswertungen
Präsentieren Sie Ihre Daten mit wenig Aufwand in grafischer Form. sevGraph unterstützt hierbei Balken-, Linien- und Stapel-Diagramme (Stacked Bars), sowie 2D- und 3D-Tortendiagramme und arbeitet vollständig datenbankunabhängig! Weitere InfosTipp des Monats Access-Tools Vol.1 
Über 400 MByte Inhalt
Mehr als 250 Access-Beispiele, 25 Add-Ins und ActiveX-Komponenten, 16 VB-Projekt inkl. Source, mehr als 320 Tipps & Tricks für Access und VB
Nur 24,95 EURWeitere Infos
|
| |
|
Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.
Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel
|
|
April 2024
Sie sind aktuell nicht angemeldet.
