| |
Allgemeine DiskussionenDaten filtern vs Daten abfragen | | | Autor: Franki | Datum: 18.01.17 04:10 |
| Hallo,
ich habe mal eine grundsätzliche Frage zu aktuellen Programmiertechniken bezüglich der Ausgabe von Daten anhand bestimmter Kriterien die der Anwender festlegen kann.
Ich kenne die Datenbankafrage schon seit Jahrzenten aus dem Bereich Datenbanken bzw. SQL. Dort kann man (ganz simpel) mit Where die Kriterien festlegen dür die Abfrage. Soweit so gut, das gibt Performance, besonder dann wenn die DB nicht lokal ist.
In letzter Zeit lese ich hier in den verschiedenen Foren immer davon, dass zuerst alle Daten eingelesen werden, dann über einen Filter die gewünschten Daten aussgefiltert bzw. angezeit werden. Das funktioniert zwar, ist aber eigentlich unnötig wenn der User vorher weiß was er als ergebnis haben möchte.
Schon die alte Windows Suche unter Win95 bis W2K hatte schon angeboten, dass man nach Dateitypen, Datum, enthaltenem Text usw. vor selektieren konnte in verschiedenen Kombinationen. Und das war performant im Vergleich dazu alles anzeigen zu lassen und dann nachher zu sortieren in der Ergebnisliste.
also meine Frage: Warum gibt es das heute nicht mehr und die meisten Antworten auf entsprechende Fragen lesen erst mal alles ein (in ein Grid, ein Array, eine Collection, eine List(Of irgendwas) und filtern dann erst die Daten aus die der User sehen möchte?
Es kann ja nicht sein, dass aufgrund der heutigen Rechnerleistung das so üblich ist, bzw. es keinen nennenswerten Zeitunterschied mehr gibt und man das jetzt so macht...
Kontraproduktiv ist das immer noch bei langsamen Netzwerkverbindungen, langsamer Onlinegeschwindigkeit wenn übers Netz abgefragt wird, bzw. wenn bei mobilen Anwendungen der Traffic noch Geld kostet bzw. ab einem bestimmten Datenvolumen in der Geschwindigkeit die Abfrage sehr langsam ist.
Bin gespannt auf eure Antworten...
Gruß
Frank | |
Re: Daten filtern vs Daten abfragen | | | Autor: Manfred X | Datum: 18.01.17 06:23 |
| Hallo!
Du scheinst bei DB-Abfragen die Alternative entweder "alle" Daten oder
sehr "stark selektives" Filtern anzunehmen.
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.
Wie Du schon geschrieben hast, geht dabei einerseits z.B. um
Performance, Netzbelastung und Speicherbedarf, andererseits
auch um Daten-Sicherheit (Minimierung der abgefragten Daten
auf die "wirklich" benötigte Information; Minimierung der
Anzahl der Zugriffe bei nicht-lokalen Datenbanken).
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.
Ein denkbarer Weg bei der Verarbeitung großer Datenmengen ....
1. Erstellung integrierter DB-Methoden, die ermitteln und ausgeben,
wie viele Datensätze einer Abfrage entsprechen würden.
2. Gestaltung alternativer Abfragen mit unterschiedlich starker Selektion
in den Where-Bedingungen.
3. Festlegung einer geeigneten Zielgröße für die Zahl der Datensätze
pro Abfrage.
4. Ausführung der Abfrage, die eine Anzahl von Sätzen überträgt,
die dieser Zielgröße am nächsten kommt. | |
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 | |
Re: Daten filtern vs Daten abfragen | | | Autor: Manfred X | Datum: 19.01.17 09:32 |
| Hallo!
Die Abfrage einzelner Datensätze aus einer DB ist - insbesondere
bei Fernabfragen über ein Netzwerk - meistens wenig empfehlenswert.
Gewöhnlich steht eine Liste von Artikeln oder Rechnungen zur Bearbeitung
an. In dem Fall ist es eher zweckmäßig, in nur einer Abfrage alle Datensätze
der Liste zusammenzufassen und nach Abschluß der Bearbeitung ein Update
durchzuführen - falls in einer Multiuser-DB die temporäre Write-Sperre
dieser Sätze für andere User keine Probleme macht.
Die Anzahl der Datensätze, die einer Abfrage entsprechen, steht unter
gewissen Filterbedingungen nicht vorher fest (z.B. alle Bestellungen eines
Kunden, alle Bestellungen innerhalb eines Zeitraums).
Man sollte in voluminösen DBs deshalb eine Vorab-Bestimmung durchführen
und erst danach (z.B. per Code) entscheiden, ob die Abfrage anhand eines
geeigneten Split-Kriteriums aufzugliedern ist.
"Alte" DB-Mechanismen, auf denen ADO Classic beruht, lassen sich kaum noch mit
der Integration aktueller Datenbank-Technologien (z.B. durch Entity-Framework)
vergleichen. Man profitiert davon nur durch eine modernisierte "Denke". | |
Re: Daten filtern vs Daten abfragen | | | Autor: Franki | Datum: 20.01.17 03:53 |
| Hallo Manfred X,
Zitat: | |
Die Abfrage einzelner Datensätze aus einer DB ist -
insbesondere bei Fernabfragen über ein Netzwerk - meistens wenig
empfehlenswert. | |
Warum ist das so? Wenn ich doch genau weiß, dass ich z.B. die Telefonnummer von Kunde 4711 oder den Preis von Artikel 0815 ändern möchte, dann brauche ich weder alle Kunden noch Artikel einzulesen.
Zitat: | |
Gewöhnlich steht eine Liste von Artikeln oder Rechnungen zur
Bearbeitung an. In dem Fall ist es eher zweckmäßig, in nur einer Abfrage
alle Datensätze der Liste zusammenzufassen und nach Abschluß der Bearbeitung
ein Update durchzuführen
| |
Ja natürlich, das ist übliche Praxis, aber auch hier habe ich immer vorher selektiert. Beispiel: Ein Onlineshop mit 1 Mio Artikeln hat immer mehrere Warengruppen/Untergruppen. Da habe ich bisher z.B. bei einer Preisänderung nur die Warengruppe/Untergruppe eingelesen der Lieferant z.B. die Preise geändert hat. (Computer/Hardware/Grafikkarten/LieferantXY) Da brauche ich doch nur die Grakas des Lieferanten XY und nicht alle Artikel in der Hauptgruppe Computer...
Zitat: | |
- falls in einer Multiuser-DB die temporäre
Write-Sperre dieser Sätze für andere User keine Probleme macht.
| |
Das ist ein ganz anderes Thema was durchaus zu berücksichtigen ist...
Zitat: | |
Die Anzahl der Datensätze, die einer Abfrage entsprechen,
steht unter gewissen Filterbedingungen nicht vorher fest (z.B. alle
Bestellungen eines Kunden, alle Bestellungen innerhalb eines Zeitraums).
Man sollte in voluminösen DBs deshalb eine Vorab-Bestimmung
durchführen und erst danach (z.B. per Code) entscheiden, ob die Abfrage
anhand eines geeigneten Split-Kriteriums aufzugliedern ist.
| |
Genau das war ja meine Frage: Die Vorab-Bestimmung ist ja das was über das Select... durchgeführt wird anstatt alles einzulesen und das dann clientseitig zu filtern. Du hast meine Frage hiermit sozusagen indirekt beantwortet, bzw. meine Meinung bestätigt.
Zitat: | |
Alte DB-Mechanismen, auf denen ADO Classic beruht, lassen sich kaum noch mit
der Integration aktueller Datenbank-Technologien (z.B. durch
Entity-Framework) vergleichen. Man profitiert davon nur durch eine
modernisierte Denke. | |
Na ja, du hast schon recht, aber ob jetzt ADO Classic oder ADO.Net oder sonst was, die Technologien haben sich geändert, sie lassen sich vergleichen, aber dennoch zählt unter dem Strich die Performance für den User.
Und dem ist es völlig egal was man verwendet, Hauptsache er hat die Performance bzw. Geschwindigkeit die er möchte bzw. gewohnt ist. Ich kann keinem Kunden hier in der Provinz verkaufen, dass ich von ADO Classic auf ADO.NET umsteige und er länger braucht seine Ergebnisse von Abfragen bei Datenbanken die nur online zu erreichen sind zu sehen.
Deswegen lege ich ja auch Wert darauf, dass der Traffic so gering wie möglich gehalten wird. Früher unter DOS gab es Wettbewerbe wo man um jedes Byte gekämpft hat, oder später sogenannte Golf-Turniere wo es auch schon um Performance ging.
Im heutigen Zeitalter scheint es mir, dass Performance nicht wirklich eine Rolle mehr spielt wenn man gut ausgerüstet ist in Sachen Internetverbindung usw. Aber dennoch ist der Overhead von unnötigem Traffic bei vielen Unternehmen leider kein Thema.
Gruß
Frank | |
Re: Daten filtern vs Daten abfragen | | | Autor: Manfred X | Datum: 20.01.17 10:07 |
| [I]Wenn ich doch genau weiß, dass ich z.B. die Telefonnummer von Kunde 4711
oder den Preis von Artikel 0815 ändern möchte, dann brauche ich weder alle
Kunden noch Artikel einzulesen.[/I]
Selbstverständlich nicht.
Der übliche Anwendungsfall ist aber nicht, daß man nur ein Feld in einem
Datensatz aktualisieren möchte und das war's.
Man ermittelt Datenpakete für die anstehende Bearbeitung.
Es geht um die zweckmäßige Gestaltung der lokalen "In-Memory-DB" (Entkopplung der DB),
die durch eine geeignete Abfrage erstellt und als Basis für die weiteren Dialoge
genutzt wird. (Eventuell gibt der User zunächst eine Liste von Datensätzen oder
Satzgruppen vor, die er benötigt - Auswahldialoge.)
Performance-Probleme existieren gewöhnlich nicht, weil Datennachforderungen
oder DB-Updates während der User-Bearbeitung durch Hintergrundprozesse niederer
Priorität abgewickelt werden können. Und Daten-gebundene UI-Controls sind ohne
User-Wartezeit auf die neu gefüllten Datenquellen umzusetzen.
Wie oben erwähnt, ist die Minimierung des Netz-Traffic nur ein Aspekt der
Gesamt-Performance und der Datensicherheit. Es geht z.B. auch um die
Minimierung der Häufigkeit der Abfragen oder die Überprüfung der internen
Konsistenz der aktualisierten Daten (lokal definierte Regeln der Anwendung
oder Regeln in der DB - Update über Stored Procedures).
Beitrag wurde zuletzt am 20.01.17 um 10:20:26 editiert. | |
| 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 |
|
|
Neu! sevCommand 4.0
Professionelle Schaltflächen im modernen Design!
Mit nur wenigen Mausklicks statten auch Sie Ihre Anwendungen ab sofort mit grafischen Schaltflächen im modernen Look & Feel aus (WinXP, Office, Vista oder auch Windows 8), inkl. große Symbolbibliothek. Weitere InfosTipp des Monats TOP Entwickler-Paket
TOP-Preis!!
Mit der Developer CD erhalten Sie insgesamt 24 Entwickler- komponenten und Windows-DLLs. Die Einzelkomponenten haben einen Gesamtwert von 1605.50 EUR...
Jetzt nur 599,00 EURWeitere Infos
|