Dataset Grundsatzfrage zum Daten laden

  • VB.NET

Es gibt 3 Antworten in diesem Thema. Der letzte Beitrag () ist von KBT.

    Dataset Grundsatzfrage zum Daten laden

    Hallo zusammen,

    im Visual-Studio-Dataset-Designer kann man wunderbar die Tabellen und Beziehungen im Dataset zueinander darstellen, welches dann super im Code zur Verfügung steht. Ich kann ja im Designer aber keine dynamischen Where-Klauseln hinterlegen - jedenfalls wüsste ich nicht wo, was für mich bedeutet, dass immer alle Daten eingelesen werden (außer ich definiere im TableAdapter selbst die where-Klausel, was aber nicht geht, weil wir mal die oder die Daten benötigen)

    Ich frage mich, was passiert mit wirklich großen Datenmengen? Wir werden in Zukunft Tabellen haben, die wahrscheinlich über eine Million Zeilen haben werden.

    Ich will nicht auf die definierten Datasets des Designers verzichten, aber wenn die Performance nicht stimmt, ist das auch nicht so förderlich.

    Also die Fragen sind
    - wo würdet ihr auf Datasets des Designers verzichten,
    - wo ist die zeitliche kritische Grenze? (OK, die ist je nach System unterschiedlich, aber wenn ein User 10-20 Sekunden bei bestimmten Aktionen warten müssen, wird der Frust nicht weniger),

    Vielen Dank schon mal für das Feedback.
    für kleine Datenmengen ( so bis 20000 Datensätze, oder 50MB-Datei) reicht ein typDataset völlig.
    Also um erstmal eine Anwendung featureComplete zu programmieren.
    Im Produktiv-Betrieb können natürlich größere Mengen auftreten, dann verwendet man halt eine Datenbank - zusätzlich!
    Betrachte eine Datenbank einfach als eine andere Datensenke, als es die Dataset-Datei ist.
    Diese neue Datensenke hat die Möglichkeit, auch nur Auszüge aus den Daten ins Dataset zu laden, wo eine Datei immer komplett rein muss.

    Wie gesagt: Die Anwendung bleibt im wesentlichen dieselbe - dasselbe Dataset, dieselben Bindings, dieselbe Businesslogik.
    Nur geladen/weggeschrieben wirds in eine andere Datensenke.

    Es gibt auch Connectoren, bzw. für Access und SqlServer sind sie OnBord.
    Diese Connectoren generieren dir aus einer Datenbank das entsprechende typDataset.

    Ich hingegen habe den Spiess umgedreht, und mir ein Tool gebastelt, was aus einem gegebenen typDataset in einer leeren Datenbank die Tabellen anlegt.
    NATÜRLICH! DANKE DANKE!!!

    man, wie konnte ich so blind sein!
    Im Prinzip machen wir das schon mit unseren Aktions-Protokolldaten. Hier liegen nur Daten, die nicht älter als x-Wochen sind. Alles was drüber geht, wird in eine andere DB bzw. Tabelle geschoben!
    ​Wenn der User doch mal "ältere" Daten will, muss er halt ins "Archiv gehen".

    UND NOCH MAL DANKE!

    tut mir leid, dass ich euch so damit behelligt habe.
    Bei uns regeln wir viel über StoredProcedures auf der Datenbank und jagen das dann (typisiert und untypisiert je nach Fall und Vorliebe) ins Frontend. Untypisiert hat bei uns oft den Vorteil dass die Stored Procedure und teilweise sogar die Datenbankstruktur verändert werden kann ohne das Frontend anfassen zu müssen. Sowas wie eine dynamische Where-Klausel habe ich auch gerade programmiert auf folgende Weise:

    User wählt aus einer Liste etwas aus und möchte zu diesem Punkt Daten haben. Die Liste liegt in der Datenbank mit Zusatzinformationen wo die Daten liegen, wie sie vorliegen usw. Der ausgewählte Punkt (oder mehrere) werden an eine SP geschickt, welche dann nachguckt wie die Punkte zu bearbeiten sind und schickt Daten zurück an das Frontend. Lege ich nun neue "Arten" von Punkten an, muss ich das Frontend nicht editieren, nur meine Stored Procedure. Ist natürlich nur eine Möglichkeit sowas umzusetzen

    ​Zeitlich kritische Grenzen haben wir (in der Regel 30sec), verdichten aber teilweise die Daten auf der Datenbank durch SPs, sollten zu viele Daten anlaufen. Man kann z.B. mit Count gucken wie viele Datensätze abgefragt werden. Sind es über x Punkte verdichtet man die Daten (z.B. Wochenweise Mittelwerte/Minima/Maxima), sind es weniger einfach alles roh.

    Will man beispielsweise Datenreihen visualisieren in einem Diagramm, machen mehr als Datenpunkte als Pixel auf dem Bildschirm sind wenig Sinn. Es wird sowieso nicht so viel dargestellt wie angefordert. Also verdichten wir die vor.