|
| |
Allgemeine Diskussionen| 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 | |
 | 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 |
 |
|
sevOutBar 4.0 
Vertikale Menüleisten
á la Outlook
Erstellen von Outlook ähnlichen Benutzer- interfaces - mit beliebig vielen Gruppen und Symboleinträgen. Moderner OfficeXP-Style mit Farbverläufen, Balloon-Tips, u.v.m. 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.
