nicht angemeldet
Hallo Franz!
Aber XML läßt sich eben leicht weitertransformieren in eine druckbare Rechnung z.B., die Werkzeugvielfalt und das Programmierer-Know-How nimmt zu. Ganz im Ggs. zu EDIFACT. XML lernt man schnell, eine komplexe DTD schon schwerer. Aber bei EDIFACT tut man sich schon schwer überhaupt das Grundprinzip zu begreifen: Transaktionen, Segmente usw.
Aber Transaktionen(damit meinst Du doch das z.B. eine Bestellung vom Gegenüber bestätigt werde müssen, oder?), haben ja nicht mit Edifact oder XML zu tun, das ist doch eher eine Frage der Semantik ob ich möchte das meine Bestellung auch bestätigt wird. Das _muss_ es dann auch in XML-basierten Standards geben, ohne solche Bestätigungen wird man das wohl nirgendwo in kritischen Bereichen durchsetzen können.
Wenn du das so hart rein kodierst oder die Struktur komplett änderst hast du recht.
was heißt "hart reinkodieren"? Was soll ich sonst machen wenn sich was an den Daten ändert?
In der Regel wirst du aber deine SW so designen, dass über Konfiguartionsmechanismen Deine SW auf sowas reagieren kann oder du nutzt Tools, die dich bei sowas in generischer Weise unterstützen.
Meinst Du sowas wie eine Oberfläche in der man manuell, also z.B. pber ein webinterface die Zuordnung von Daten zu Tabellen verändern kann? Kann mir nicht so genau vorstellen wie Du das meinst.
Fast alle DB-Hersteller bieten da Mapping-Tools von einer XML-Struktur auf eine realtionale DB-Struktur.
Was heißt mapping? Ich will einen "Datensatz" den ich als XML-Datei habe in eine relationale Datenbank eintragen, meinst Du da brauche ich gar keine eigene Software für schreiben? Gibt es sowas für MySQL oder postGreSQL? Gibts sowas auch für die Gegenrichtung?
Ja, zumindest benötigst Du eine Art von Integration. Ob die nun Point-zu-Point ist oder auf Maping basiert oder was auch immer.
Was ist da der Unterschied?
Vielen Dank und schöne Grüße,
Andreas