Übergeben verschiedener typ. DataTables

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von tragl.

    Übergeben verschiedener typ. DataTables

    Hallo,

    wenn ich eine Funktion zur Bearbeitung an Tabellen schreiben will hab ich das Problem, dass ich für jede Tabelle eine eigene Funktion brauche.
    Quasi nach CopyPaste Art

    VB.NET-Quellcode

    1. Private Sub updatetable1(dt as DataSet1.table1)
    2. For Each row In dt
    3. ...
    4. Next
    5. End Sub
    6. Private Sub updatetable2(dt as DataSet1.table2)
    7. For Each row In dt
    8. ...
    9. Next
    10. End Sub


    Das ist wohl dem geschuldet, dass die Tabellen unterschiedliche Spalten haben können; bei mir stimmen die Spalten allerdings überein.
    Also hab ich überleg alles in eine Tabelle zu tun mit einem zusätzlich Flag woher der jeweilige Eintrag kommt. Das wäre natürlich unschön.

    Wahrscheinlich brauche ich sowas wie eine Modelltabelle von der table1 und table2 die Eigenschaften erben? Aber wie setzt man das im DataSet um?

    Viele Grüße

    Haudruferzappeltnoch schrieb:

    bei mir stimmen die Spalten allerdings überein.
    Also hab ich überleg alles in eine Tabelle zu tun mit einem zusätzlich Flag woher der jeweilige Eintrag kommt. Das wäre natürlich unschön.
    nö - das wäre schön.
    Wenn mehrere Tabellen gleichartige Datensätze beinhalten, dann ist das ein Design-Fehler. Üblicherweise.
    Kann natürlich immer mal begründete Ausnahmen geben, aber ich kenne ja nicht dein Datenmodell.
    Ich frag mich nur grad, was das Ziel an einem praktischen Beispiel wär.
    Wenn ich ne Fahrrad-Tabelle und ne Auto-Tabelle habe, warum sollte ich die
    1. zusammengewürfelt bearbeiten und
    2. alle Einträge quasi gleichzeitig bearbeiten wollen?
    Punkt 2 brauch ich nur ganz selten, z.B. wenn ich was Grundlegendes an z.B. allen Fahhrädern machen will, weil ne Datenspalte in der Tabelle gefehlt hat und ich da einmalig bestimmte Defaultdaten reinsetzen will.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    Genau sowas Grundlegendes will ich tatsächlich tun, die Tabellen haben eine Datumspalte in der das Datum nicht für jeden Eintrag korrekt ist, dieser muss dementsprechend korrigiert werden.

    Also es sind schon unterschiedliche Produkte, ich habe quasi die Produktnummern und anhand der Produktart ziehe ich Informationen von verschiedenen Mengen an Produktnummern.
    Jede Menge hat also ihre eigenen Informationen über sich. Die Informationen sind gleichartig, sollen aber natürlich für die Produktarten getrennt vorliegen.

    Wenn ich also alles in eine Tabelle tue mit Produktart-Flag, dann mach ich das ja nur damit ich nicht 5 mal denselben Code für 5 Tabellen benutze. Am Ende müsste ich über den Flag ja wieder die Daten trennen.
    Das macht den Code von den Zeichen her kürzer, aber vom Ablauf her länger (wahrscheinlich nicht sonderlich messbar, nur von der Arbeitsweise her, wenn man annimmt das eine große Tabelle bearbeiten solange dauert wie entsprechend mehrere kleine)

    Also das Datenmodell ist in etwa:
    Produktart1 -> table1
    Produktart2 -> table2
    gleiche Spalten, unterschiedliche Datensätze
    Wären alle Spalten der beiden Tabellen identisch, dann wären die Produkte bei mir in einer Tabelle und es gäbe dort eine Spalte für die Produktart. Sonst müsste ich bei Erweiterungen ja zwei Tabellen pflegen.
    "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

    Haudruferzappeltnoch schrieb:


    Das macht den Code von den Zeichen her kürzer, aber vom Ablauf her länger (wahrscheinlich nicht sonderlich messbar, nur von der Arbeitsweise her, wenn man annimmt das eine große Tabelle bearbeiten solange dauert wie entsprechend mehrere kleine)
    Du hampelst also mit fünf Tabellen herum, um einen nicht messbaren angenommenen Geschwindigkeits-Vorteil herauszuoptimieren?
    Beachte die 3 Rules of Optimization

    Haudruferzappeltnoch schrieb:

    Also es sind schon unterschiedliche Produkte, ich habe quasi die Produktnummern und anhand der Produktart ziehe ich Informationen von verschiedenen Mengen an Produktnummern.
    Jede Menge hat also ihre eigenen Informationen über sich. Die Informationen sind gleichartig, sollen aber natürlich für die Produktarten getrennt vorliegen.
    So einer abstrahierten Beschreibung wird kein Mensch folgen können (ich kanns jdfs nicht).
    Willst du über dein Datenmodell sprechen, zeig es bitte (Dataset-Screenshot).
    Naja die Produkte haben natürlich unterschiedliche Eigenschaften, daher kommen ja die unterschiedlichen Tabellen, die benötigten Eigenschaften liegen bei allen Arten gleichermaßen vor

    Theoretisch hast du also recht @mrMo die Pflege ist aufwendig. Das ist aber nur die Theorie, Erweiterungen an den Tabellen gibt es nicht.

    Ich weiß nicht genau wie ein Datenmodell für euch aussehen soll. Table1 hat Identifikationsnummern ein Erstelldatum und Stueckzahl, das hat Table2 genauso. Die Inhalte sind unterschiedliche.
    Die getrennten Tabellen sind dann wohl schlecht aber da hab ich keine Aktien drin, so muss es.

    @ErfinderDesRades Es geht ja nicht um eine aufwendige Optimierung. Es geht auch nicht um Geschwindigkeiten, sondern nur um die Möglichkeiten die man denn hätte und ums Lernen.
    Das mit der Geschwindigkeit sagte ich nur weil ich nicht generell Programmgeschwindigkeit der Codelänge unterordnen würde.
    Wenn die Antwort ist, dass anderes Vorgehen als mein Vorschlag zu umständlich ist dann ist das halt so.


    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Haudruferzappeltnoch“ ()

    Haudruferzappeltnoch schrieb:

    Naja die Produkte haben natürlich unterschiedliche Eigenschaften, daher kommen ja die unterschiedlichen Tabellen, die benötigten Eigenschaften liegen bei allen Arten gleichermaßen vor
    Das die Werte an sich unterschiedlich sind ist klar. Die Eigenschaften (Nummer, Datum, Stueck) jedoch sind identisch. Demnach gehört alles in die gleiche Tabelle.
    "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
    was du da zeigst ist ja auch nicht dein konkretes Datenmodell.
    was du da zeigst ist ein offsichtlicher Designfehler: Die beiden Tabellen müssen eine sein.

    Wie ich gelegentlich sage: Es ist sinnlos über Code zu sprechen, den es konkret nicht gibt. Das gilt wohl auch für Datenmodelle.



    Ich vermute übrigens fast, dass du da iwie an ein Kernproblem relationaler Datenbänkerei stösst: relationale Entitäten kennen keine objektorientierte Vererbung.
    also relational kann man wunnebar Äpfel, Birnen, Kirschen modellieren - aber eine gemeinsame Basisklasse Obst - das ist im relationalen Ansatz leider nicht wirklich vorgesehen.

    Aber das ist nur eine Vermutung meinerseits, die ich quasi darauf stütze, dasses Schwierigkeiten gibt, dein Problem mir verständlich zu kommunizieren.
    Also wie die anderen auch schon gesagt haben: Dein Datenmodell (von dem, was du uns zeigst) macht überhaupt keinen Sinn. Alles in eine Tabelle und dann eine Spalte für die Produkart oder was auch immer.
    Ansonsten warum machst du aus:

    Haudruferzappeltnoch schrieb:

    Quasi nach CopyPaste Art

    VB.NET-Quellcode
    Private Sub updatetable1(dt as DataSet1.table1)
    For Each row In dt
    ...
    Next
    End Sub
    Private Sub updatetable2(dt as DataSet1.table2)
    For Each row In dt
    ...
    Next
    End Sub


    nicht:

    VB.NET-Quellcode

    1. Private Sub updatetable(dt as DataTable)
    2. For Each row In dt
    3. ...
    4. Next
    5. End Sub


    und übergibst die Datatable? Dabei spielt es keine Rolle ob typisiert oder nicht eine DataSet1.table2 ist auch eine DataTable

    Davon abgesehn würd ich so gravierende Änderung (z.B. jeden Datensatz einer Table) nicht irgendwo im Programm anbieten.
    Bei mir fällt sowas an, wenn ich ne Spalte nachträglich ergänze und brauch da default-Werte. Dann ruf' ich beim Programmieren einmalig den Code auf, der
    das für mich erledigt und danach fliegt er wieder raus. Sowas sollte man keinem User in die Hände geben.

    Wenn du die Live-Datenbank nicht da hast beim Programmieren, dann muss sowas einmalig beim Programmupdate ablaufen.
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:
    Achso naja User bin ich quasi selbst, also von der Perspektive geb ich das niemandem in die Hände sozusagen

    Wenn ich es als untypisierte DataTable übergebe, dann scheitert es. Die untypisierte DataTable dt ist keine Sammlung die man in einer Schleife durchlaufen kann. dt.Rows() müsste als Gegenstück herhalten.
    Die Spalten haben da dann auch keine Namen mehr. Würde wohl gehen mit den Zahlen zu hantieren, aber deswegen benutzt man ja typisierte Dts damit man das nicht hat. Zumindest war das ein Grund den ich vernommen habe.