nicht angemeldet
Hallo Thomas !
Zunächst einmal zum Thema "Mumpitz"
es ist aber eine etwas merkwürdige art ein für dich interessantes thema als "unsinn", "dummes gerade" (eben Mumpitz) zu bezeichenen.
was soll da meiner einer denken?
Du sollst denken: "Dem zeig ich jetzt aber, dass er Unrecht hat"! :-)
Es besitz ein jeder Message eine unique ID.
Ich finde ja toll, dass jede Message eine ID besitzt. Solange http://forum.de.selfhtml.org/?m=33223 aber nicht "funzt", nützt es mir wenig.
Und man könnte messages dadurch ansprechen, es könnten dadurch sogar deep-links in messages gesetzt und verfolgt werden, bidirektionale links sind auch kein problem. Dies wäre mit XLink problemlos möglich.
Zumindest theoretisch. Im Prinzip sind "Links" aber doch auch nicht viel anderes als "Relationen", außer dass sie vielleicht etwas willkürlicher eingestreut werden können, als nach dem relationalen Datenmodell.
Und wieder muss ich die Frage stellen: warum ist es unsere und XML schuld, wenn die entsprechende software noch in kinderschuhen steckt und nicht so unglaublich altehrwürdig und überreif ist wie eine DB.
Statt 'überreif' hätte ich lieber 'ausgereift' gehört. ;-(
Man muss, denke ich, einfach abwarten, ob die ganzen X-Dingens, die lustig definiert werden, sich überhaupt praktikabel umsetzen lassen. Ich muss gestehen, dass ich den Überblick schon lange verloren habe.
Es ist ja nun nicht so, dass in einem relationalem Datenmodell die Bezüge zum Context nicht auch erhalten blieben.
*LOL* klar bleiben sie erhalten in tausenden von tabellen die, um eben diesen kontext nachbilden zu können (weil von erhalten kann dabei keines falls die rede sein), wiederum durch eigene indexe miteinander verknüpft werden.
(du weisst schon tabelle für "Autor" im delta- und für "titel" im gamma-quadrant)
Es bleibt eine Ansichtssache: Der von dir so über alles gestellte Kontext ist in meinen Augen nur _einer_ von vielen und wird daher nach dem relationalen Datenmodell über Abfragen, Queries oder (ganz bildlich) Views dargestellt.
(vergleich bibliothek:} [...] buch (posting) [...] themenkreis (thread)[...] und genau dieses hierarchische prinzip wird bei bibliotheken verfolgt)
aber wenn in dem buch auf ein anderes buch zum selben thema bezug genommen wird, hast du probleme
Wenn in dem Buch aber auf ein anderes Buch aus einem anderen Themenbereich Bezug genommen wird, hast du das Problem.
ja und? damit sind wir aber erst jetzt dort wo wir mit einer DB von anfang an stehen.
Nicht ohne Grund finden sich in Bibliotheken allerlei verschiedene Register, die neben der thematischen eben auch eine autor- oder verlagsbezogene Sortierung der Bücher bieten.
register wären aber RDF oder TopicMaps also wiederum eine XML-"Anwendung" (nein, ich werde dir hier nicht erklären was diesen beiden Mumpitze sind, aber du kannst beim W3C bzw. bei topicmaps.org nachlesen)
Entweder bei mir fällt jetzt langsam aber sicher der entscheidende Groschen, oder aber ich dreh' ganz einfach mächtig am Rad :-) 'Mal weitergucken...
Und: Was wäre die (Buch-) Welt ohne ISBN?
1000 jahre kam bücher ohne ISBN aus. und in den bibliotheken sind vorwiegend bucher ohne ISBN gelagert.
ISBN ist sehr nützlich, aber was hat das mit DB und XML zu tun?
ISBN sollte nur als (Paradebeispiel) für eine unique-id herhalten, dem Grundprinzip des relationalen Datenbankmodells.
kannst du dort aus der DB alle gewünschten formate so super schnell erzeugen? das wäre mir was ganz neues.
Theoretisch zumindest: ja!
warum plötzlich nur theoretsich?
Weil die Praxis immer etwas anders aussieht als die Theorie. Dies ist nichts XML-spezifisches! >:-)
ich frage mich eigentlich warum leute sich immer wieder und nur an der performance anecken, wohl sonst keine andere argumente gegen xml!?
Für mich ist Performance ein _enorm_ wichtiges Argument. Daher würde es mir als einziges Gegenargument schon reichen.
es wurden hier schon mehrere gegenargumente genannt, angfangen von der hierarchischen struktur, bis hin zu plattform und software unabhängigen möglichkeit von datenaustausch.
Noch einmal deutlich: Wenn die Performance beim Ganzen nicht stimmt, dann kann man das ganze schöne Konzept von XML glatt in die Tonne treten.
Ähnlich einem Auto: Da können tausend Airbags drin sein, sprachgesteuerte Klimaautomatik, satelliten-gesteuertes Navigationssystem mit Autopilot etc. Wenn's nicht fährt ...
übrigens, wenn DB an sich doch so toll ist, warum arbeiten so sehr die DB hersteller an der XML unterstützung ihrer DBs?
Das muss nun wirklich gar nichts heißen. Wenn z.B. die Kunden von Mickysoft nicht einsehen wollen, warum sie ein teures Update auf Wort XY, wo es die alte Version doch auch "tut", dann muss eben etwas revolutionär neues aus dem Hut gezaubert werden, damit die Kasse wieder klingelt. ;-)
hier redet jeder von professionellen DBs und dann von unserem hausgemachten forum mit eingenen perl-parser etc.
Nicht nur. Wir reden in puncto Performance auch über die Suchfunktion des Forumsarchivs, die IIRC nicht die XML-Dateien direkt, sondern - eben aus Geschwindigkeitsgründen - eine CSV-Datei durchsucht.
du sprichst nach wie vor von unserem forum gegen einer professionellen db.
Dass eine CSV-Datei eine professionelle DB wäre, wäre mir jetzt allerdings ganz neu. =:O
hätten wir das geld, würde ich sofort eine xml-db einsetzen wollen und dann kümmert mich kein csv-datei mehr.
Apropos Geld: Wie sieht es eigentlich mit Freeware/Open Source in Sachen XML-DBMS aus? MySQL kost' ja z.B. nix.
Vielleicht erklärst du mir in wenigen Sätzen die Vorteile, die dieses DBMS gegenüber "alten" DBMS wie Oracle/MySQL bietet?
sorry, aber was interssieren mich ein Mumpitz wie Oracle oder MySQL ?! *fg*
Gut gekontert! *g*
Dies ist übrigens meine Ausgangsfrage gewesen, nur ein wenig anders formuliert.
ganz und gar nicht! hier stellst du die richtige frage, vorher wolltest du eine software (eine DB) mit einem dateiformat (xml) vergleichen. (und ich hoffe du siehst ein, warum diese fragestellung nicht richtig war)
Tja, ich muss gestehen, da habe auch ich die Begrifflichkeiten nicht immer sauber getrennt. Ob du jetzt allerdings richtiger liegst, ziehe ich hiermit in Zweifel:
Eine Datenbank (DB) ist für mich nicht mehr als eine irgendwie geartete Ansammlung von Daten.
Ein Datenbankmanagementsystem (DBMS) ist eine Software, die eine DB verwaltet, organisiert usw. "managet" halt.
MySQL ist ein DBMS, das Daten nach dem relationalen Datenbankmodell verwaltet.
XML ist - wie der Name schon sagt - eine Sprache. Ein Dateiformat ist es m.E. nicht!
... langsam komme ich der Antwort auf alle Fragen oder aber dem Wahnsinn näher ...
diese diskussion fordert wirkliche aufmerksamkeit und ich bin aber einfach zu mnüde dazu, deshalb nur lesestoff:
http://www.softwareag.com/tamino/
http://www.ixiasoft.com/support/doc/textml_server_doc.asp
http://www.ixiasoft.com/support/doc/Introducing.pdf
http://www.exceloncorp.com/products/datasheets/xis_24jan02.pdf
Ich habe mir den von dir verlinkten Lesestoff 'mal zu Gemüte geführt.
Viel mehr als Werbung war das allerdings nicht. Und von einzigartigen Funktionen, die mir diese DBMSs böten, habe ich auch nichts gesehen, außer dass sie eben mit XML arbeiten.
Etwas weiter hat mich schon der Besuch auf <www.xml.org> gebracht. Hier vor allem der Überblick über die vielen XML-"Dialekte", an denen die Industrie mehr oder weniger fleißig arbeitet.
Dort gibt es dann z.B. eine "Small and Medium Sized Business XML" (SMBXML), eine "Human Resources Markup Language" (HRML) oder auch so etwas witziges wie eine "Chess Game Markup Language" (ChessGML).
Also alles Sprachen bzw. DTDs, die ein Format beschreiben, in welchem Daten für einen bestimmten Verwendungszweck strukturiert sein sollten, damit Firmen, Organisationen oder auch einfach nur Schachfreunde weltweit Daten standardisiert und ohne Sprachprobleme austauschen können.
Anders ausgedrückt: Mit Hilfe von XML werden für jeden nur erdenklichen Anwendungsfall (maschinenlesbare) "Formulare" (soundsoML) bzw. entsprechende Ausfüllanleitungen (DTDs) entwickelt, die jeder (Mensch oder Maschine) lesen kann, sofern er denn XML lesen kann.
Ich hoffe, bis hierhin liege ich noch halbwegs richtig!?
Nun aber kommt der entscheidene Punkt zwischen Genie und Wahnsinn ;-) :
Wenn ich jetzt nicht ein paar entscheidende Punkte übersehen habe (mittlerweile ist es ja auch recht früh bzw. spät geworden), ist doch stets nur von XML-Dokumenten die Rede, nie aber von Dateien.
Sowie ich es jetzt verstehe, ist ein XML-Dokument in etwa vergleichbar mit einem "View" auf eine relationale DB, also vielmehr ein virtuelles "Etwas" als ein Dokument oder gar eine Datei. Wie die tatsächlichen Daten, also die Bits und Bytes, auf der Festplatte gespeichert werden, wird nirgends festgelegt und geht auch keinen etwas an.
Ich habe also bei mir eine Datenbank, die ich in XML angelegt habe mit einer entsprechenden DTD. XML dient dabei (ähnlich wie SQL) lediglich der Verständigung zwischen mir und dem Server. Was dieser daraus macht, ist sein Bier. Theoretisch könnte er die Elemente, die ich in der XML angelegt habe, nehmen, analysieren und intern in relationalen Tabellen speichern. ;-)
Will nun jemand von mir einen Bericht in einer bestimmten Form, gibt es mir seine DTD für diesen Bericht und übersetze meine Daten aus meinem XML-Dokument mithilfe von Übersetzungsregeln, die ich per XSLT (?) festlege, in die von ihm gewünschte Form. Wenn ich jetzt nicht komplett auf dem Holzweg bin, habe ich dadurch die Daten aber nicht zwangsläufig wirklich doppelt irgendwo gespeichert, sondern habe nur 2 verschiedene Dokument-Ansichten auf denselben (physikalischen) Datenbestand definiert.
Habe ich das Prinzip jetzt verstanden oder war das ein völliges Hirngespinst meinerseits?
Bei letzterem bitte ich nicht etwa um einen Gnadenschuß ;-), sondern einfach um Richtigstellung.
was tabellen in einer DB angeht:
ist ja ekelhaft. :-)
Schlag mich tot: Ich find's toll! :-)
Sancta simplicitas!! :-þ
Na, herzlichen Dank auch! :-D
Gruß,
kerki