Hallo Thomas !
Zunächst einmal zum Thema "Mumpitz"
Ich stelle mich gerne etwas blöd, wenn ich befürchte, dass eine in meinen Augen sehr interessante Diskussion frühzeitig im Sande verläuft. :-)
Zudem stand deutlich dabei "aus meiner derzeitigen Sicht".
Andersherum fielen mir reichlich Dinge ein, die mit DBMS-gestützter Datenhaltung besser oder einfacher zu machen wären.
nämlich?
Da stehen doch schon einmal 3:
Beispiele sieht man ja heute schon an der Vielpoststatistik oder an den Statistiken von Carsten, die - wenn ich nicht irre - schon heute mit Hilfe von MySQL erstellt werden. Auch ein Querverweisen in archivierten Beiträgen wäre m.E. kein Problem mehr, wenn man jeden Beitrag einfach über seine ID ansprechen könnte.
beides sind ohne MySQL möglich. mit XSLT kann ebenso jedes beliebige Detail eines Thread oder Messages gefiltert werden.
das Carsten das nicht macht kannst du bitte wohl kaum der XML vorwerfen!
Wieso beides? Auf meinen dritten und vielleicht wichtigsten Punkt bist du gar nicht eingegangen. Für den kann Carsten gar nichts. Vielmehr handelt es sich um eine konzeptionelle Schwäche dieser Forumsarchivierung, die - zugegebenermaßen - auch nicht in XML begründet ist.
----- zitat ---
[...]
Eine posting-bezogene Datenspeicherung wäre deutlich flexibler, und unter diesem Gesichtspunkt spricht dann auch nicht mehr viel gegen eine RDBMS-basierte Lösung. :-)
sorry, aber das ist doch unsinnig, ein postig kann natürlich ein posting unter vielen sein, aber ohne seine bezüge zu parent/child (=thread)ist es sinnlos. [...] wenn du dabei nur tausende von einzelpostig hast, bist du gelindegesagt aufgeschmissen.
Es ist ja nun nicht so, dass in einem relationalem Datenmodell die Bezüge zum Context nicht auch erhalten blieben.
(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.
Dumm ist auch, wenn ein Buch gleichermaßen gut zwei oder mehreren Themenbereichen zuzuordnen ist. Oder aber mich interessieren nur die Werke eines bestimmten Autors.
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.
Und: Was wäre die (Buch-) Welt ohne ISBN?
----zitat-----
Man bekommt zwar in der XML-Datei in einem Zug eine Baumstruktur heraus, aber auch _genau_ eine. Sobald ich die Daten in einer anderen Relation ausgeben will, als in der XML vorgegeben, bin ich doch verraten und verkauft, oder nicht?
ich habe gelesen ,dass du mit verraten und verkauft die performance meintest, aber wo bitte liegt der unteschied zu DBs?
kannst du dort aus der DB alle gewünschten formate so super schnell erzeugen? das wäre mir was ganz neues.
Theoretisch zumindest: ja!
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 sind Performance ein _enorm_ wichtiges Argument. Daher würde es mir als einziges Gegenargument schon reichen.
aber die performance-argumente sind erstens ziemlich lächerlich (auch und eben im angesicht der wahlmöglichkeit zwischen DOM und und SAX), zweitens sie sind nicht haltbar.
Ich sagte ja bereits, dass ich mich mit XML noch nicht wirklich ausführlich beschäftigt habe. Daher wird dich sicherlich nicht sonderlich überraschen, dass mir DOM und SAX in diesem Zusammenhang aber auch nicht das Geringste sagen.
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.
wir dürfen über professionelle DBs reden, aber dann müssen wir auch über professionelle XML-DBs, wie Tamino, oder TextML-server reden. und die halten locker mit anderen DBs stand (ich habe schon unlägst erwähnt, dass ixiasoft (TextML) unlängst beim us-airforce seine server installiert hat)
Ich hoffe, du nimmst mir nicht übel, dass ich von Tamino noch nie etwas gehört habe.
Vielleicht erklärst du mir in wenigen Sätzen die Vorteile, die dieses DBMS gegenüber "alten" DBMS wie Oracle/MySQL bietet?
Dies ist übrigens meine Ausgangsfrage gewesen, nur ein wenig anders formuliert.
was tabellen in einer DB angeht: ich kann mir nichts graunhafters vorstellen als eine universum voller tabellen die vokommen sinnlos im space herumkugeln und sich gegenseiten mit indexen einenader zugehörig erklären. ich brauch etwas dann wird es aus einer tabelle geholt und wenn ich etwas, was noch dazugehört haben will, wird es aus einer anderen tabelle die 3 lichtjahre weiter entfernt ist besorgt.
ist ja ekelhaft. :-)
Schlag mich tot: Ich find's toll! :-)
dagegen bietet xml nicht nur eine struktur in der das was zusammengehört auch zusammen ist an [...]
Für mich ist das, was du 'Struktur' nennst, nur eine von vielen möglichen Sichtweisen. In den Augen eines anderen Betrachters könnte diese Struktur ganz anders aussehen.
[...] sondern ermöglich es mir mit wenigen mitteln die mehrfachverwendung der informationen.
Das tut aber nun wirklich _jede_ Datenbank!
aber es genügt, du willst ja vom Mumpitz eh nichts wissen. oder?
Mumpitz! ;-)
Gruß,
kerki