+ Antworten
Ergebnis 1 bis 11 von 11

Thema: Schema-Variationen: Vor-/Nachteile?!

  1. #1
    User Viertel Megabyte Themenstarter
    Avatar von tuxedo
    Registriert seit
    06.08.2008
    Ort
    Großherzogtum Baden
    Fachbeiträge
    300
    Genannt
    8 Post(s)
    Hallo zusammen,

    XML überfordert mich gerade ein wenig was das aufstellen einer Struktur betrifft... Möglichst ist ja vieles von der Struktur her. Einiges erscheint kurz und leserlich, anderes erscheint von der Struktur her besser. Eine richtige Regel habe ich nicht gefunden. Deshalb mal ein paar Beispiele mit der Frage nach eurer Meinung:

    Beispiel 1:

    1)
    XML Code:
    1. <pa userdescription="Dachgeschoss" address="1/1/1"/>

    2)
    XML Code:
    1. <pa userdescription="Dachgeschoss">1/1/1</pa>

    3)
    XML Code:
    1. <pa>
    2.     <userdescription>Dachgeschoss</userdescription>
    3.     <address>1/1/1</address>
    4. </pa>

    Eigentlich gefällt mir 1) am besten. Einfach, übersichtlich. "Bedenken" hab ich wegen dem Attribut "address", das die eigentliche Haupt-Information für diesen Knoten enthält (siehe 2)

    Beispiel 2:

    1)
    XML Code:
    1. <parameters>
    2.     <parameter id="0" value="2"/>
    3.     <parameter id="1" value="127"/>
    4.     <parameter id="2" value="2"/>
    5.     <parameter id="3" value="127"/>
    6. </parameters>

    2)
    XML Code:
    1. <parameters>
    2.     <parameter id="0">
    3.         <value>2</>
    4.     </parameter>
    5.     <parameter id="1">
    6.         <value>127</value>
    7.     </parameter>
    8. </parameters>

    3)
    XML Code:
    1. <parameters>
    2.     <parameter>
    3.         <id>0</id>
    4.         <value>2</>
    5.     </parameter>
    6.     <parameter>
    7.         <id>1</id>
    8.         <value>127</value>
    9.     </parameter>
    10. </parameters>

    Variante 1 gefällt mir wieder am besten. Kurz und übersichtlich. Aber auch hier die gleichen Bedenken wie im Beispiel 1. "Value" ist das worum es eigentlich geht.


    Wenn ich mir anschaue wie z.B. Maven seine XMLs strukturiert, dann fällt das eher in Richtung Variante 3. Variante 1 finde ich am übersichtlichsten. Ist auch mit Java Bordmitteln am geschicktesten zu parsen (Attribute holen ist einfacher wie weitere Kind-Knoten abklappern). Eventuell geht das mit 3rd Party Libs noch besser. Aber ich würde gerne bei den Bordmitteln bleiben.

    Was sagt ihr dazu? Ist Variante 1 "okay" oder eher ein "schlechter Stil"?! Welche der drei Varianten würdet ihr bevorzugen? Oder hat noch jemand eine weitere Variante?!

    Gruß
    Alex
    SIMON, das bessere RMI ... -> Projektseite (Support nur im dortigen Support-Forum)

  2. #2
    Frequent User Halbes Megabyte
    Registriert seit
    31.07.2013
    Ort
    Hamburg
    Fachbeiträge
    557
    Genannt
    56 Post(s)
    Blog-Einträge
    2
    Bei der Definition von XML-Strukturen orientiere ich mich immer ein bischen daran, wie man es in Java modellieren würde, also:
    - Primitive (Integer, Boolean, String etc.) als Attribut. Einzige Ausnahme: "Lange" Strings, z.B. Texte (in der DB-Welt CLOBs) dafür ein extra Text-Element
    - Komplexe Objekte (alles, was man in Java als eigene Klasse modellieren würde, plus Collections) als Element.
    - Namenskonvention genauso wie in Java, sprich Attribute klein-CamelCase, Elemente groß-Camelcase

    Die XML-Definitionen von Maven oder bspw. web.xml halte ich in Stellen für missglückt, weil viel zu verbos.

    P.S. Address ist so ein Grenzfall. Vordergründig lässt sich das als primitives Attribut darstellen. Langfristig wird sich dieses aber evtl. zu einem komplexen Typen weiterentwickeln (kann man aus der Ferne nicht sagen). Hier ist die Herausforderung eine ähnliche wie beim Normalisieren von DB-Schemata.
    Geändert von nillehammer (27.10.2014 um 14:44 Uhr)

  3. #3
    Frequent User Floppy Disc Avatar von Bleiglanz
    Registriert seit
    31.07.2013
    Fachbeiträge
    761
    Genannt
    99 Post(s)
    the million dollar question!

    Du bist wahrscheinlich nicht erstaunt, wenn ich dir sage, dass diese Design-Frage seit der Erfindung von XML ohne abschließende Antwort diskutiert wird:

    http://stackoverflow.com/questions/1...es-vs-elements

    http://stackoverflow.com/questions/3...vs-xml-element
    Yeah, well, you know, that's just, like, your opinion, man.

  4. #4
    User Viertel Megabyte Themenstarter
    Avatar von tuxedo
    Registriert seit
    06.08.2008
    Ort
    Großherzogtum Baden
    Fachbeiträge
    300
    Genannt
    8 Post(s)
    @nillehammer
    Address: Da "address" eine Hardwareadresse abbildet, ist es äußerst unwahrscheintlich dass sich das nochmal ändert (hat es in den letzten 23 Jahren nicht) und der "Typ" komplexer wird. Wenn dieser Fall doch mal eintritt, werde ich wohl so oder so Version 2.0 der Struktur brauchen.
    @Bleiglanz
    Ja, das habe ich befürchtet bzw. gehofft. Denn dann könnte ich ruhigen Gewissens bei Variante 1 bleiben. Oder hat noch jemand einen guten Grund in der Schublade unbedingt Variante 2 oder 3 zu verwenden?!
    SIMON, das bessere RMI ... -> Projektseite (Support nur im dortigen Support-Forum)

  5. #5
    Frequent User Floppy Disc Avatar von Bleiglanz
    Registriert seit
    31.07.2013
    Fachbeiträge
    761
    Genannt
    99 Post(s)
    Zitat Zitat von tuxedo Beitrag anzeigen
    @nillehammer
    Address: Da "address" eine Hardwareadresse abbildet, ist es äußerst unwahrscheintlich dass sich das nochmal ändert (hat es in den letzten 23 Jahren nicht) und der "Typ" komplexer wird. Wenn dieser Fall doch mal eintritt, werde ich wohl so oder so Version 2.0 der Struktur brauchen.
    @Bleiglanz
    Ja, das habe ich befürchtet bzw. gehofft. Denn dann könnte ich ruhigen Gewissens bei Variante 1 bleiben. Oder hat noch jemand einen guten Grund in der Schublade unbedingt Variante 2 oder 3 zu verwenden?!
    Wenn du für alle Zukunft ausschließen kannst, dass z.B. mal zwei oder Adressen da sind - und du das mal erweitern musst und schon "Bestandsdokumente" da sind (WÜRG), dann ist 1 schon ok.

    3 ist halt am flexibelsten, wenn mal irgendwann Änderungen kommen die rückwärtskompatibel abgehandelt werden sollen.

    Übrigens nimmt heutzutage scheinbar eh jeder Hinz einfach JSON für Konfigurationsdateien, wenn er kann.
    Yeah, well, you know, that's just, like, your opinion, man.

  6. #6
    User Viertel Megabyte Themenstarter
    Avatar von tuxedo
    Registriert seit
    06.08.2008
    Ort
    Großherzogtum Baden
    Fachbeiträge
    300
    Genannt
    8 Post(s)
    Ja, das kann ich bis auf weiteres ausschließen. Ein Gerät kann nur eine gültige Adresse haben. Das war die letzten Jahrzehnte so, und wird allein schon aus kompatibilitätsgründen auch die nächsten Jahrzehnte so bleiben. Wenn es jemals ein Update des Protokolls das die Geräte sprechen gibt, dann wird eh ein neues Format fällig.

    Das XML-Format ist auc nur für Konfigurationsdateien gedacht die geparst, interpretiert und sehr rudimentär und hardwarenah auf Mikrocontroller geschrieben werden. Gleich nach dem parsen ist das Format irrelevant für das Zielsystem. Ich hab also keine weiteren Abhängigkeiten. Von daher bin ich da recht frei im Design des Formats.

    Json hab ich mir auch überlegt. Aber XML in dieser einfachen Struktur bekommt auch ein Nicht-Entwickler zusammengebastelt/editiert.
    SIMON, das bessere RMI ... -> Projektseite (Support nur im dortigen Support-Forum)

  7. #7
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.716
    Genannt
    291 Post(s)
    Zitat Zitat von tuxedo Beitrag anzeigen
    Oder hat noch jemand eine weitere Variante?!
    Beispiel 1.3 ist ja interessanterweise eher nicht 2.1, nicht 2.2, nicht 2.3, sondern noch neues 2.4:
    XML Code:
    1.     <parameters>
    2.         <parameter id="0">2</parameter>
    3.         <parameter id="1">127</parameter>
    4.         <parameter id="2">2</parameter>
    5.         <parameter id="3">127</parameter>
    6.     </parameters>

    die ganze Aufteilung von Beispiel 2 passt zum ersten Beispiel sowieso nicht besonders,
    willst du/ betrachtest du generische Parameter-Tags mit Id oder individuell benannte Tags wie userdescription

    außerdem ist alles Beispiel 2 sauber auf einzelne Informationspaare ausgelegt, während in Beispiel 1.1 mehrere Attribute zusammenstehen, unterschiedlicher gehts ja kaum,
    eine besondere Empfehlung habe ich leider nicht, aber nochmal diese Anomalie aufzeigend wäre
    XML Code:
    1.     <pa>
    2.         <userdescription value="Dachgeschoss" />
    3.         <address value="1/1/1" />
    4.     </pa>
    ein noch nicht geposteter Schnippel der es zu betrachten wert ist,
    kombininiert das präferierte 2.1 mit der Macht individueller Tags (spart id),
    vermeidet die Attributansammlung, welche allerdings nicht direkt schlecht sein muss

    ist quasi 1.3, nur besser in 2.1 gelernt

    ab 100.000facher Verwendung empfehle ich v statt value -> 100.000x 5 Zeichen eingespart
    Hansa wird Meister

  8. #8
    Global Moderator Floppy Disc Avatar von Tomate_Salat
    Registriert seit
    30.07.2013
    Ort
    Durlach
    Fachbeiträge
    784
    Genannt
    154 Post(s)
    Blog-Einträge
    4
    Ich würde mir dazu mal richtige Objekte/Typen inkl. Wertebereiche definieren. z.B.: ... description hört sich für mich nach einem potentiell längeren Text an. Das würde ich dann als CDATA in ein eigenen Tag packen:
    XML Code:
    1.  
    2. <userdescription><![CDATA[Hallo welt, hier steht
    3. ein toller text]]>
    4. </userdescription>

    Als Attribute würde ich glaub nur wichtige Sachen packen, die z.B. für einen Konstruktor interessant sein würden (z.B. address oder ne id). Setter könnten dann wiederrum als eigene Tags dienen:
    XML Code:
    1.  
    2. <person>
    3.     <name>Karl Heiner</name> <!-- ruft später person.setName("Karl Heiner"); auf -->
    4. </person>

    Das letzte mal, als ich eine XML-Datei für unser Produkt definiert habe, hat da auch viel vom beabsichtigten Verarbeitungsweg eine Rolle gespielt (+ die Tatsache, dass diese einfach erweiterbar sein soll).
    byte-welt.net - das Forum von Programmierern für Programmierer

    Naming Conventions
    Schema-Variationen: Vor-/Nachteile?!

    JMapper | Instant Note (App)

  9. #9
    User Viertel Megabyte Themenstarter
    Avatar von tuxedo
    Registriert seit
    06.08.2008
    Ort
    Großherzogtum Baden
    Fachbeiträge
    300
    Genannt
    8 Post(s)
    Zitat Zitat von SlaterB Beitrag anzeigen
    XML Code:
    1.     <parameters>
    2.         <parameter id="0">2</parameter>
    3.         <parameter id="1">127</parameter>
    4.         <parameter id="2">2</parameter>
    5.         <parameter id="3">127</parameter>
    6.     </parameters>
    Hmm, interessant. Gefällt mir auch recht gut. Das würde passen, wenn es tatsächlich bei einem einzigen Wert pro Parameter bleibt.

    willst du/ betrachtest du generische Parameter-Tags mit Id oder individuell benannte Tags wie userdescription
    In gezeigtem Parameter-Beispiel. referenziert "id" einen anderen knoten irgendwo im XML Baum. Kurz gefasst:
    Ein Abschnitt beschreibt ein Gerät mit möglichen Parametern, und der andere Abschnitt "konfiguriert" diese Parameter. Die Trennung in knoten ist beabsichtigt und gewollt.
    Aber du hast recht: so richtig getrennt zwischen Dingen die quasi fest vorgegeben sind, und dingen die individuell sind, hab ich nicht. Wenn nur jeweils ein Wert individuell ist, dann passt dein 2.5 Beispiel jedenfalls.

    außerdem ist alles Beispiel 2 sauber auf einzelne Informationspaare ausgelegt, während in Beispiel 1.1 mehrere Attribute zusammenstehen, unterschiedlicher gehts ja kaum,
    Dein Text liest sich irgendwie schwer?! Warst du in Eile?

    Bei Beispiel 1 geht es um das Ding namens "PA". In Java würde man das wohl so abbilden

    Java Code:
    1. public class PA {
    2.  
    3.     String userdescription;
    4.     String address;
    5.  
    6. }

    Eine ID gibt es nicht. PA hält auch keine Referenzen auf anderes.
    Mein naiver Ansatz war (damit es übersichtlich bleibt): Beide vom Benutzer beeinflussbaren Werte des PA in je ein Attribut fassen.
    Deshalb stehen da mehrere Attribute zusammen. Beide Beschreiben PA.

    eine besondere Empfehlung habe ich leider nicht, aber nochmal diese Anomalie aufzeigend wäre
    XML Code:
    1.     <pa>
    2.         <userdescription value="Dachgeschoss" />
    3.         <address value="1/1/1" />
    4.     </pa>
    ein noch nicht geposteter Schnippel der es zu betrachten wert ist,
    In Anbetracht der Einfachheit von PA (Ein Ding mit 2 Werten) sieht das etwas nach Overkill aus.


    Parameter ist übrigens ähnlich einfach aufgebaut. Könnte man so abbilden:

    Java Code:
    1. public class Parameter {
    2.  
    3.     int id;
    4.     byte value;
    5.  
    6. }
    SIMON, das bessere RMI ... -> Projektseite (Support nur im dortigen Support-Forum)

  10. #10
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.716
    Genannt
    291 Post(s)
    Zitat Zitat von tuxedo Beitrag anzeigen
    In Anbetracht der Einfachheit von PA (Ein Ding mit 2 Werten) sieht das etwas nach Overkill aus.
    es ist nur deine selber aufgeworfene Variante 1.3 verbessert auf 2.1

    wenn PA wirklich so klein und endgültig ist, dann sieht
    XML Code:
    1. <pa userdescription="Dachgeschoss">1/1/1</pa>
    sparsamer aus, oder als Overkill in die andere Richtung, meinetwegen Underkill:
    XML Code:
    1. <pa Dachgeschoss="1/1/1"/>
    aber beliebige Parameter als Attributnamen zu nehmen ist wohl nicht besonders klug, Leerzeichen etwa Problem,

    1.1 mit den zwei Attributen ist sicherlich das Beste (falls nicht konkrete Probleme dagegen sprechen, ich habe nichts)
    und dabei noch erweiterbar, drei oder mehr Attribute gingen auch

    -----

    na, soviel noch als Rückmeldung, und mein Schreibstil sollte zumindest einem langjährigen Mitglied wie dir doch eigentlich bekannt, wenn nicht geläufig sein, hätte ich vermutet
    Geändert von SlaterB (27.10.2014 um 16:02 Uhr)
    Hansa wird Meister

  11. #11
    User Halbes Megabyte Avatar von Crian
    Registriert seit
    02.08.2013
    Fachbeiträge
    552
    Genannt
    32 Post(s)
    Off topic:
    Ich mag SlaterBs Schreibstil. Den erkenne ich auch sofort, ohne auf den Benutzer links zu schauen.


    Zum Thema: Ich habe mich in einer ähnlichen Situation für Variante 3 entschieden, da die Dateien vom Programm geschrieben und gelesen werden und so robust Änderungen gegenüber sind.

+ Antworten Thema als "gelöst" markieren

Direkt antworten Direkt antworten

Die chemische Formel von Wasser lautet ... ?

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. Webentwicklung: Agentur vs Inhouse - Vor- und Nachteile
    Von KrokvsKrok im Forum Spielwiese
    Antworten: 4
    Letzter Beitrag: 19.08.2014, 17:30
  2. Schema in SQL Server Management Studio
    Von Movementroboter im Forum Allgemeines
    Antworten: 6
    Letzter Beitrag: 15.08.2013, 10:08
  3. Schema in SQL Server Management Studio
    Von Movementroboter im Forum Datenbankprogrammierung
    Antworten: 6
    Letzter Beitrag: 15.08.2013, 10:08
  4. Product Review: Schema Compare for Oracle
    Von RSS Reader im Forum simple-talk - category SQL
    Antworten: 0
    Letzter Beitrag: 23.07.2010, 23:30
  5. Exploring your database schema with SQL
    Von RSS Reader im Forum simple-talk - category SQL
    Antworten: 0
    Letzter Beitrag: 04.03.2010, 16:27

Stichworte

Berechtigungen

  • Neue Themen erstellen: Ja
  • Themen beantworten: Ja
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •