MySQL - Filter-Performance

  • VB.NET

Es gibt 5 Antworten in diesem Thema. Der letzte Beitrag () ist von Mono.

    MySQL - Filter-Performance

    Was ist von der Performance besser? 7

    Das Ergebnis ist nur für Teilnehmer sichtbar.

    Hi :)

    Ich wollte mal fragen was von der Performance her besser ist:
    • Eine WHERE Abfrage in der Command Query zum filtern der Rows
    • Alle Daten der Tabelle holen und im Code Filtern
    Oder spielt das Komplett keine Rolle?

    LG Luca

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „0luca0“ ()

    Nunja prinzipiell ist der Server der Bediener (to serve = dienen) und der Client der Bediente.

    Server sind darauf ausgelegt diese Arbeit zu verrichten, also in Größe und Datenmenge, der Client hat nur im geringst nötigen Fall was damit zu tun.
    Polling is trolling!

    Achtung: Ich habe die komische Angewohnheit, simple Dinge zu verkomplizieren..
    Als Grundlage der Abstimmung müsste der Server und der Client 100% identische Leistungsmerkmale haben. Zudem müsste der Client 100% identischen Code wie der Server ausführen. Die Übermittlung der Daten an den Client/Server darf hier auch nicht in die Bewertung einbezogen werden.

    Da in der praxis der Server Hardware- und Softwaremäßig aber auf das Verteilen von Daten optimiert ist, wird wohl die Verarbeitung der Daten auf dem Server schneller sein.

    Andernfalls, bei 100% Identischem Code und 100% gleicher Hard- und Software werden wohl die Ergebnisse identisch sein.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    0luca0 schrieb:

    Alle Daten der Tabelle holen und im Code Filtern
    das wird bei einer sehr großen Anzahl von Datensätzen nichts bringen und den Arbeitsspeicher unnötig überfordern - das Filtern lässt man den Server machen und dann landen die Daten in den Arbeitsspeicher des Client...
    alle Daten holen, und im Client filtern ist das schnellste - wenn die Daten erstmal geholt sind. Also der Startup verzögert sich vlt. um 1s, aber dann ist die Performance optimal.
    Es ist allerdings unpraktikabel bei zu großen Datenbeständen ( ca. > 20000 Datensätze )

    Und andersrum: Wenn es praktikabel ist, dann erhebt sich die Frage, wozu die Datenbank?
    Weil alle Datensätze laden geht schneller und einfacher, indem das Dataset direkt von Platte gelesen wird.

    Ach und noch zur Option "Kommt nicht drauf an" - Das musst du doch wissen, obs drauf ankommt. Bei Ladezeiten unter 300ms kommts vlt. nicht drauf an, und auch die genannte Initial-Ladezeit von 1s beim Startup - kommts dir da drauf an?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Also wenn du nur eine Tabelle hast ist eine MySQL Datenbank komplett oversized.
    Normalerweise verwendet man viele Tabellen die in Relationen zueinander stehen usw.

    Wenn es lediglich darum geht eine Tabelle einmal abzufragen, dann wäre das WHERE direkt am SQL Server 100% schneller als alles zu laden und dann am client zu Filtern.
    Filterst du öfter und änderst was etc dann wäre es am Client schneller.
    Deine Frage ist etwas zu ungenau und ohne Rahmenbedingungen daher schwer beantwortbar.
    Das ist meine Signatur und sie wird wunderbar sein!