XML aus DataSet mit geschachtelten Beziehungen

  • VB.NET
  • .NET 5–6

Es gibt 12 Antworten in diesem Thema. Der letzte Beitrag () ist von VB1963.

    XML aus DataSet mit geschachtelten Beziehungen

    Hallo,

    Habe da als Beispiel eine Tabelle Auto und eine Tabelle Farbe.
    Dann lege ich eine geschachtelte Beziehung zwischen Auto und Farbe an.

    Ich erzeuge Daten:

    VB.NET-Quellcode

    1. Dim auto1 = DS1._Auto.AddAutoRow(1, "Ferrari", 1)
    2. DS1.Farbe.AddFarbeRow(auto1, "rot")
    3. DS1.AcceptChanges()
    4. DS1.WriteXml("DS1.xml")
    und kriege diese Xml:

    XML-Quellcode

    1. <DataSet1 xmlns="http://tempuri.org/DataSet1.xsd">
    2. <Auto>
    3. <ID>1</ID>
    4. <Modell>Ferrari</Modell>
    5. <FarbeID>1</FarbeID> 'Doppelmoppel
    6. <Farbe>
    7. <ID>1</ID>
    8. <Name>rot</Name>
    9. </Farbe>
    10. </Auto>
    11. </DataSet1>

    Zum Einen finde ich es komisch das Auto dafür die übergeordnete Tabelle sein muss, ich muss also für jede Auto-Zeile auch eine neue Farb-Zeile anlegen.
    Zum Anderen würde ich gerne den FarbeID Eintrag loswerden, der ist unter Farbe/ID ja schon drin.

    Lässt sich das einstellen? Oder muss ich das selbstbasteln?

    Viele Grüße

    Ich versteh grad Deine Verwirrung nicht. Ich kenne zwar Dein tDS-Design nicht, aber wenn Farbe eine Abhängigkeit zu Auto hat, also eine AutoID braucht und ohne Auto nicht existieren kann, warum sollte dann diese XML keine Sinn ergeben? Außerdem gewährleistet ja diese Datenhaltung, dass mithilfe des tDS-Codes die Farbtabelle unabhängig von Auto-Einträgen angesprochen werden kann (Farbe.GetAllFarbeRows oder sowas). Aber in der XML existiert Farbe nicht als eigene Tabelle, weil es - wie geschrieben - keinen Sinn ergeben würde. Die XML ist so also schon richtig. Farben sind Autos zu- und untergeordnet. Aber im Programm ist so gewährleistet, dass sie unabängig von den Autos ansprechbar sind.
    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.

    Also ich sollte dazu sagen mir gehts hier um die Erzeugung der XML.
    Das DataSet finde ich da einfach aufgrund der Visualisierung sehr nützlich (eine Art miss-use). Ich habe da ein etwas größeres Datenmodell im Kopf. Wenns nicht geht, dann gehts natürlich nicht, ist auch kein Problem.

    @VaporiZed
    Ich habe nirgendwo geschrieben, dass die XML keinen Sinn ergibt. Nein, ich will die Xml schon so haben, nur halt ohne den FarbeID-Eintrag. Notfalls mach ich es eben ohne DataSet.
    Mit gefiele mir schlicht besser.
    Normalerweise würde ich in einem DataSet diese Tabellen so anlegen, dass Farbe den Autos übergeordnet wäre. Es gibt eine Farbe nun mal nur einmal. Und wenns eine Farbe nicht gibt, kann es auch kein Auto in dieser Farbe geben. Aber gut für eine Xml in der Struktur wie ich es brauche muss Farbe eben untergeordnet sein, dass orientiert sich eher an dem Konzept Klasse-Eigenschaft. Eine Klasse kann ja an sich ohne eine bestimmte Eigenschaft existieren. Das ist in Datenmodell ja oft nicht so gehalten.

    ErfinderDesRades schrieb:

    na, denn lösch doch die Spalte FarbeID aus deiner Table Auto
    Na wo tu ich dann die Abhängigkeit hin? Der Code oben im Post ist vollständig, bis auf Methodenrumpf
    Der Designer hat wirklich nicht mehr als oben beschrieben. Hab ich ja entsprechend zum Test nur beispielhaft mit erstellt.

    ErfinderDesRades schrieb:

    Und Auto.FarbeID ist auch kein PK
    Das stimmt das ist es auch nicht, der Schlüssel den man da sieht, ist ein FK

    ErfinderDesRades schrieb:

    Die Relation ist falschrum
    Auch das stimmt, aber ist nicht neu. Bitte lese auch was ich schreibe.
    Für das DataSet isses falschrum. Für die xml isses "richtig rum".

    Haudruferzappeltnoch schrieb:

    <FarbeID>1</FarbeID> 'Doppelmoppel

    Was möchtest du jetzt für ein Datenmodel haben?
    Tabelle Auto --> Tabelle Farbe (1:n-Beziehung) oder umgekehrt...

    Geschachtelte Beziehung unterscheidet sich in der .XML-Datei folgend:

    XML-Quellcode

    1. Geschachtelte Beziehung von AUTO --> Farbe (1:n)
    2. <?xml version="1.0" standalone="yes"?>
    3. <DS1 xmlns="http://tempuri.org/DataSet1.xsd">
    4. <Auto>
    5. <ID>-1</ID>
    6. <Model>Ferrari</Model>
    7. <Farbe>
    8. <ID>-1</ID>
    9. <AutoID>-1</AutoID>
    10. <Name>rot</Name>
    11. </Farbe>
    12. </Auto>
    13. </DS1>
    15. NICHT geschachtelte Beziehung von AUTO --> Farbe (1:n)
    16. <?xml version="1.0" standalone="yes"?>
    17. <DS1 xmlns="http://tempuri.org/DataSet1.xsd">
    18. <Farbe>
    19. <ID>-1</ID>
    20. <AutoID>-1</AutoID>
    21. <Name>rot</Name>
    22. </Farbe>
    23. <Auto>
    24. <ID>-1</ID>
    25. <Model>Ferrari</Model>
    26. </Auto>
    27. </DS1>
    Im Endeffekt ist das Datenmodel das Gleiche...

    Die Xml, die ich möchte soll so aussehen:

    XML-Quellcode

    1. <DataSet1 xmlns="http://tempuri.org/DataSet1.xsd">
    2. <Auto>
    3. <ID>1</ID>
    4. <Modell>Ferrari</Modell>
    5. <Farbe>
    6. <ID>1</ID>
    7. <Name>rot</Name>
    8. </Farbe>
    9. </Auto>
    10. </DataSet1>
    Ich weiß auch dass ich das erreichen kann, wenn ich kein DataSet verwende sondern eine Auto-Klasse und eine zugehörige Farbe-Klasse bastel. Und daraus entsprechend eine Xml erzeuge.

    Nur wenn es mit DataSet auch geht, dann hätte ich das gerne.

    VB1963 schrieb:

    Was möchtest du jetzt für ein Datenmodel haben?
    In diesem Sinne ist mir also das Datenmodell egal, ich mach es so wie man es dafür machen müsste.

    Aber jetzt hast du mich auf was gebracht.
    Ja so gehts, ich konnte mich nicht von diesen Fremdschlüsselspalten lösen, die sonst dazugehören.

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

    Aber was willst du eiglich bezwecken?
    So wird für jedes Auto eine eigene Farbe erzeugt.
    Das sind mehr XmlElemente als nötig.
    Mit einem "korrekten" Datenmodell gäbe es nur so viele Farben, wie es gibt, und die Auto-XmlElemente wären in die Farb-XmlElemente eingeschachtelt. Das FarbeID-Element (der Doppelmoppel) würde aufgrund der Verschachtelung verschwinden.
    In meinen Augen das optimale Xml - was ist daran nicht ok?

    @ErfinderDesRades Die Frage will ich dir gerne erneut beantworten. Ich brauche nicht zwangsläufig eine "funktionale/optimale" Xml, sie muss erstmal nur geschachtelt sein.

    Nun gibt es dafür mehrere Möglichkeiten das zu erreichen.

    Warum will ich das mit einem DataSet machen? Weil die Übersicht mir gefällt.

    Vielleicht sollte ich meine Beispiel-Tabellen umbennenen, dann wird das klarer. Auto und Farbe haben zu viel Kontext.

    XML-Quellcode

    1. <Whatever>
    2. <Aussen>
    3. <ID>1</ID>
    4. <DataColumn1>Foo</Modell>
    5. <Innen>
    6. <ID>1</ID>
    7. <DataColumn1>Bar</Name>
    8. </Innen>
    9. </Aussen>
    10. </Whatever>

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

    So, ich glaub, endlich habichs gerafft. Dein Xml wird aber bischen anders rauskommen:

    XML-Quellcode

    1. <Whatever>
    2. <Aussen>
    3. <ID>1</ID>
    4. <DataColumn1>Foo</Modell>
    5. <Innen>
    6. <DataColumn1>Bar</Name>
    7. </Innen>
    8. </Aussen>
    9. </Whatever>
    Die Fremdschlüssel-Werte verschwinden ja bei einer geschachtelten Beziehung.
    Unvermeidbar aber der PK.
    Allerdings wenn Aussen.DataColumn1 unique ist - dann kannste das als PK nehmen, um Innen.ID damit zu verknüpfen.

    Ups, habe den Namen von DataColumn1 nicht richtig ergänzt, aber egal...

    Ne, die ID von Innen (der Fremdschlüssel) ist noch mit dabei. Aber das ist nicht so schlimm.
    Wir sind jetzt schon in dem Beispiel, wo keine gedoppelten IDs mehr vorkommen. Es sind ja nun jeweils die IDs der eigenen Tabelle, vorher hatte ich ja noch eine InnenID-Spalte in der Aussen-Tabelle reingetüdelt.
    Da war das löschen aus Post 3 schon der richtige Hinweis, musste ich nur erstmal einsehen.

    Auch wenn Aussen.DataColumn1 unique ist (was bei mir der Fall sein wird), ist nicht gewährleistet, dass es in jedem Fall ein Integer ist.

Facebook
Telefonspende