SqlDataAdapter und MySQL

  • VB.NET
  • .NET (FX) 3.0–3.5

Es gibt 25 Antworten in diesem Thema. Der letzte Beitrag () ist von hirnwunde.

    TTTWWRRSSSS - Datenbänkerisch ist das überaus unschön, weil das ist ja ein Super-Schlüssel, der auf evtl. sogar 3 externe Entitäten verweist: Auf ein Bauteil, auf ein Werkzeug, auf eine Revision.
    Und dazu wird noch der lokale Primärschlüssel angehängt: die Seriennummer.

    Dann lass das halt so, weil das wird recht aufwändig, es datenbänkerisch korrekt aufzudröseln.
    Als Perspektive - wäre es aufgedröselt, dann würde sich die Möglichkeit eröffnen, etwa alle Messungen eines Werkzeugs abzurufen oder sowas.
    Kann man auch so abrufen - kriegt man nur 'nen Vogel bei, weil das wird ein Heiden-Gewerkel mit String-Operationen etc.

    hirnwunde schrieb:

    Bist Du da mit mir einer Meinung, dass ich anstatt einer XML-Datei hier auf einer Datenbank angewiesen bin?
    nö - Du bist überhaupt nicht auf eine Datenbank angewiesen.
    Was soll eine DB denn da können, was das Dataset nicht selbst und viel einfacher kann?

    ErfinderDesRades schrieb:

    alle Messungen eines Werkzeugs abzurufen


    Das löse ich doch mit dem SQL-Query

    SQL-Abfrage

    1. SELECT * FROM `messwerte` WHERE `TXLCode` LIKE "GR102%";

    Ganz ohne Stringverdrehungen. :whistling:

    ErfinderDesRades schrieb:

    Was soll eine DB denn da können

    Verhindern, dass Arbeitsplatz (AP) 2 sich die XML-Datei läd, paar Arbeiten macht, und sie anschliessend speichert.
    Wärenddessen hat aber Arbeitsplatz 1 schon wieder eine andere Version geschrieben.
    Somit wären die Änderungen von AP1 verloren, da ja die (eigenstaendige) Anwendung von AP2 nicht von der Arbeit an der XML-Datei an AP1 weiss.

    Die Datei "locken" kann ich auch nicht - denn es sollen ja beide APs simultan arbeiten können.

    ok - du willst eine Multi-User-Anwendung - das kann eine XmlDatei nicht.

    Trotzdem empfehle ich, den Kram DatasetOnly zu entwickeln, und die DB hintanzustellen.
    Die Multi-User-Fähigkeit kannst du eh erst am Ende implementieren, wenn alles annere so weit schoma fertig ist.

    Und sonen Filter wie du zeigst, kann BindingSource.Filter übrigens auch, also soo schlimm kompliziert wirds vlt. doch nicht.
    Bliebe noch die Datenkonsistenz, die bei sonem "SuperSchlüssel" nicht gewährleistet werden kann.
    Bei ordentlichen Relationen kann man Constraints setzen, die absolut sicher verhindern, dass korrupte Daten Eingang finden.
    Beim "SuperSchlüssel" kann zunächstmal jeder Hurgler da iwelche Phantasie-Werkzeug-/Bauteil-/Revision-Schlüssel-Segmente eingeben, ein Tippfehler kann die Anwendung instabil machen.
    Aber wie gesagt: lasses erstmal so.

    Hach Mensch ;)
    Ich kann Dich verstehen!
    Dein Vorwissen bzgl. der Themen ist um ein grosses Vielfachens höher als bei mir. :)

    Bzgl. der Inkonsitenz:
    Bei der Eingabe der Daten findet aktuell eine Überprüfung statt, ob es bspw. das Tool überhaupt gibt oder ob die Revision des Tools schon freigegeben ist.
    Des weiteren sind wir ein kleines Unternehmen, mit sehr spezialisierten Mitarbeitern, die sich der Wichtigkeit der Konsistenz unserer Bauteildaten durchaus bewusst sind.
    Ja, Fehler sind nciht auszuschliessen. Aber diese halten sich immer soweit im Rahmen, das ich diese korrigieren kann.
    Gegen Mutwilligkeit (wo ich mir bei keinem unserer MAs Angst drum machen müsste) kann ich schliesslich kein solches Programm, wo Daten eingetragen werden, schützen.
    Das mag möglich sein, ja. Aber diesen Aufwand brauche ich bei 3 Leuten, die die DB befüllen, nicht treiben.

    Das wäre bei einem Unternehmen mit mehreren 100en MAs und mehreren Standorten ohne Frage ein ganz anderers Thema.
    Aber dort werden ja auch Profis, wie Du, für solche Sachen beschäftigt/beauftragt :)

    Nach dem, was ich auf Wikipedia bzgl eines Superschlüssels gelesen habe, kann ich glaube mit der Gefahr leben, die er in sich birgt. ;)

    echt - gibts einen Wiki-Artikel dazu? Ich hab das Wort nämlich selbst erfunden.

    Tatsache - gibt einen Treffer.
    Aber den Artikel verstehe ich nicht recht, und glaub die verwenden den Begriff anders. - ich meine mit "SuperSchlüssel" eine Spalte, in der mehrere Fremd (und hier auch der Prim-) Schlüssel in einem einzigen String zusammengemanscht sind: TTTWWRRSSSS

    Also Verweise auf 3 übergeordnete Entitäten plus eindeutige SerienNummer - sowas gehört eigentlich auf 4 Spalten aufgeteilt.

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

    ErfinderDesRades schrieb:

    nämlich selbst erfunden

    Scheinbar ja nicht :P

    Ok. Jetzt verstehe ich auch, was Du mit SuperSchlüssel meinst.
    Liegt der Nachteil in diesem Fall daran, das man sich die Suche erschwehrt, weil man viel mehr Datensätze als nötig aus der Db holt und diese im Nachhinein nochmals Filtern muss?
    Das wäre jetzt zumindest das Einzige was mir in den Sinn kommt.
    Und ja. Das ist natürlich weder für das DBMS, noch für den Client, der dann nochmals Filtern müsste, sinnvoll.
    Aber bei den <10.000 Datensätzen in diesem Fall eher vernachlässigbar.
    Selbst mein BananaPi liefert ein Query auf alle Datensätze mit verschiedenen WHERE-Klauseln in Millisekunden.

    Dennoch werde ich bei der nächsten Version der Datenbank und den Tools, die meine MAs einsetzen werden, ein neues DB-Konzept verwirklichen ;)
    Immer brav Deinen Ratschlägen folgend :D

Facebook
Telefonspende