Heise installiert Forum auf MySQl-Basis

[andreas]

Hallo!
Wir hatten ja kürzlich eine kleine interessante Diskussion bzgl. Forensoftware - XML/Datenbank...
wollte nur kurz sagen dass Heise auf ein MySQL-basiertes Forum umstellt.
http://www.heise.de/newsticker/data/mw-27.02.02-000/ ;-)

Viele Grüße
  Andreas

[Achim Schrepfer]

Hi,

Wir hatten ja kürzlich eine kleine interessante Diskussion bzgl. Forensoftware - XML/Datenbank...
wollte nur kurz sagen dass Heise auf ein MySQL-basiertes Forum umstellt.
http://www.heise.de/newsticker/data/mw-27.02.02-000/ ;-)

Du kannst es wohl nicht lassen, oder? ;-)

Viele Grüsse,
Achim

[andreas]

Hi!
Mensch, laßt mir doch auch mal wenigstens ein kleines bisschen Bestätigung! Und ich hab Euch wohl verstanden, deswegen auch nur "Zur Info"!
Also nix gegen dieses Forum, aber vor allem geht es mit mehr um den Inhalt, und der ist hier mit das beste was ich kenne, und wenn die Profis unter Euch die Software für mit die beste die es gibt halten, glaub ich das wohl und wir leben alle glücklich und zufrieden bis ans Ende unserer Tage...
Grüße
  Andreas

[Achim Schrepfer]

Hi,

Mensch, laßt mir doch auch mal wenigstens ein kleines bisschen Bestätigung! Und ich hab Euch wohl verstanden, deswegen auch nur "Zur Info"!

ich hoff, Du hast meinen Smiley ;-) nicht übersehen und nimmst mein Posting dementsprechend gelassen.

Viele Grüsse
Achim

[andreas]

Hi!

ich hoff, Du hast meinen Smiley ;-) nicht übersehen und nimmst mein Posting dementsprechend gelassen.

Keine Sorge, mein Puls ist wieder unter 150!

Grüße
  Andreas

[Stefan Muenz]

Hallo Andreas,

Keine Sorge, mein Puls ist wieder unter 150!

Oh, dann pass aber auf, dass er nicht irgendwann wieder hoch geht: die Oberflaeche des Meeres ist manchmal ruhiger als seine Tiefen ... und es gibt durchaus andere EDV-Konzepte, die auch was von Geschwindigkeit verstehen ;-)

viele Gruesse
  Stefan Muenz

[Christian Kruse]

Hoi Stefan,

Keine Sorge, mein Puls ist wieder unter 150!

Oh, dann pass aber auf, dass er nicht irgendwann wieder hoch geht: die
Oberflaeche des Meeres ist manchmal ruhiger als seine Tiefen ... und es gibt
durchaus andere EDV-Konzepte, die auch was von Geschwindigkeit verstehen ;-)

Pssst! ;-)

Gruesse,
 CK

[Schuer]

Hi!

wollte nur kurz sagen dass Heise auf ein MySQL-basiertes Forum umstellt.

Wie, Heise hat ein Forum?!?! Seit wann das denn? Ich dachte bisher immer, Heise hätte gar nichts interaktives, bis auf meist dümmliche Einzelkommentare meist unwissender Stümper unter den News-Meldungen...

*SCNR* ;-)

Gruß,
_Dirk

P.S. : Zweiter!

[andreas]

Hi!
Ja, das konnte man wirklich nicht Forum nennen, war so ziemlich das bekloppteste was ich an "Foren"-Software je gesehen habe, so blöd zu lesen!
Dann halt: "Heise bekommt ein echtes Datenabank-basiertes Forum welches noch lange nicht so gut wie das SELFFORUM ist!"
So zufrieden?

Grüße
  Andreas

[Thomas Meinike]

Hallo,

Wir hatten ja kürzlich eine kleine interessante Diskussion bzgl. Forensoftware - XML/Datenbank...
wollte nur kurz sagen dass Heise auf ein MySQL-basiertes Forum umstellt.
http://www.heise.de/newsticker/data/mw-27.02.02-000/ ;-)

Ist ja an sich 'ne schoene Sache, die auch die Leistungsgfaehigkeit von MySQL bei großen Projekten unter Beweis stellen kann. Wenn die NASA damit arbeitet, kann heise das wohl auch ;-).

Nach dem letzten iX-Vergleichsartikel zwischen MySQL und PostgreSQL haette ich aber eher auf den Einsatz des letztgenannten RDBMS getippt.

Die (inhaltliche) Attraktivitaet des heise-Forums wird man dadurch vermutlich aber nicht steigern koennen ...

MfG, Thomas

[Achim Schrepfer]

Hi,

Nach dem letzten iX-Vergleichsartikel zwischen MySQL und PostgreSQL haette ich aber eher auf den Einsatz des letztgenannten RDBMS getippt.

wurden da auch die Benchmarks verglichen? Hab in ner Linux-Enterprise mal nen Vergleich der Benchmarks gelesen, da hat Postgre ganz schön die Flügel gestreckt. Ich kanns zwar nicht beurteilen, weil ich Postgre noch nie installiert hab, aber ich glaub der LE einfach mal...

Viele Grüsse
Achim

[Wilhelm]

Hi

wollte nur kurz sagen dass Heise auf ein MySQL-basiertes Forum umstellt.
http://www.heise.de/newsticker/data/mw-27.02.02-000/ ;-)

Und das heisst dann LiTroFo! ;-)

<subjektiv>
Da es ja nun Threadbasiert sein soll, wird es um einiges einfacher, die ueberragenden Statements der ganzen Linux-Trolls zu lesen.
</subjektiv>

Gruesse
Wilhelm

<polemik>
der damit nichts gegen Linux sagen will, in Gegenteil. Aber ein OS kann sich nun mal nicht seine Benutzer auswaehlen. ;-)
</polemik>

<objektiv>
Und es wimmelt dort auch von Windows-Trolls. Nur zur Klarstellung.
</objektiv>

25%
25%
25%
25%
25%
25%
25%
25%
25%
:-)

[Bio]

Sonst hätten Sie PostGreSQL genommen ;-)

Gruesse,

Bio

[Thomas Meinike]

Hallo,

Sonst hätten Sie PostGreSQL genommen ;-)

... aber sie hatten kein Geld fuer ein kleines "g" ;-).

MfG, Thomas

[Christian Kruse]

Hoi,

Wir hatten ja kürzlich eine kleine interessante Diskussion bzgl.
Forensoftware - XML/Datenbank...

Hatten wir? Gibst du mir mal eine URL?

Gruesse,
 CK

[kerki]

Hallo !

Wir hatten ja kürzlich eine kleine interessante Diskussion bzgl.
Forensoftware - XML/Datenbank...

Hatten wir? Gibst du mir mal eine URL?

Ich tippe auf diesen:
http://forum.de.selfhtml.org/archiv/2002/2/5381/#m30053

Gruß,

kerki

[kerki]

Hallo!

Wir hatten ja kürzlich eine kleine interessante Diskussion bzgl. Forensoftware - XML/Datenbank...
wollte nur kurz sagen dass Heise auf ein MySQL-basiertes Forum umstellt.
http://www.heise.de/newsticker/data/mw-27.02.02-000/ ;-)

Ich bin zumindest gespannt auf deren neues Forum, auch wenn ich bisher nie nicht in einem einzigen der 26.300 (!?) Heise-Foren war.

Mich würde allerdings noch viel mehr interessieren, warum sich hier so viele gegen ein DBMS-gestütztes Forum sträuben.

Oder - andersherum - würde ich gerne erfahren, warum man sich hier für eine auf XML-Datenhaltung basierende Forumssoftware entschieden hat.

Als einzige wirkliche Begründung habe ich hier bisher nur etwas von einer Art "Pilotprojekt" gehört, was man polemisch auch als "unsinnige technische Spielerei" bezeichnen könnte. Mit dieser Begründung kann ich auch ohne weiteres leben.

Nur kann ich nicht nachvollziehen, wie man sich mit dieser "dünnen" Begründung einfach so "müde lächend" von oben herab über MySQL-gestützte Foren lustig machen kann (wie z.B. in diesem Thread).

Ich wäre geradezu entzückt zu erfahren, welche Vorteile diese hier verwendete Forensoftware aufgrund ihrer XML-Datenhaltung gegenüber DBMS-gestützter Forensoftware hat. Mir fällt da keiner ein.

Andersherum fielen mir reichlich Dinge ein, die mit DBMS-gestützter Datenhaltung besser oder einfacher zu machen wären. 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.

Nur zur Sicherheit: Ich will nicht meckern! Die hier eingesetzte Forensoftware ist toll! Glaube ich zumindest. Auf meinem heimischen Server habe ich sie allerdings mangels ausreichender Perl-Kenntnisse und vorhandener Dokumentation nicht ans Laufen bekommen.

Mir geht es aber mehr um XML vs. DBMS (z.B. MySQL).

Vielleicht habe ich mich mit XML noch nicht ausführlich genug beschäftigt. Dies mag aber auch daran liegen, dass ich den Sinn dahinter noch nicht verstehe. Aus meiner derzeitigen Sicht ist XML  schlichtweg der größte Mumpitz seit Erfindung des Computers.

Vielleicht erklärt mir ja 'mal jemand in groben Zügen, welche Vorteile XML gegenüber anderen Techniken im Allgemeinen und hinsichtlich beispielsweise einem Einsatz für ein Forum im Speziellen überhaupt hat.

Vielen Dank im Voraus für ein wenig Erleuchtung! :-)

Gruß,

kerki

Viele Grüße
  Andreas

[Daniela Koller]

Hi Kerki

Mir geht es aber mehr um XML vs. DBMS (z.B. MySQL).

Das Hauptproblem bei relationalen Datenbanken ist, eine hierarchische Struktur
wie sie Threads haben zu speichern. Im Normalfall werden einfach alle Links
gespeichert, also Parent x, hat Kinder y,z ... Es ist kein Problem, jeweils alle
Kinderposting eines Parents rauszuholen, hingegen ist es mit Standard SQL
kaum möglich, bereits einen perfekt sortierten Baum aus der Datenbank zu kriegen
der bereits alle Angaben zur Einrückung enthält. (Soviel ich weis, gibt es
mit PL/SQL also Oracle, und uu auch PostgreSQL aber die Möglichkeit das zu
lösen).

Also muss pro Thread sozusagen für jedes Posting einzeln alle Kinder geholt
werden, und das ist sehr aufwändig weil jedesmal eine neue Anfrage an das
DBMS gestellt werden muss.

Es gibt hier zwar Möglichkeiten mit PostingIDs wie ThreadID.Posting.Posting.Posting...
zu arbeiten um die Hierarchie zu speichern, dafür muss die ID dann aber als
String gespeichert werden und von einem Script gemäss Punkten in dem String
richtig geparst werden, die Reihenfolgte stimmt jedoch schon direkt aus der
Datenbank und ein aufwändiger Sortiervorgang ist nicht nötig.

Gruss Daniela

[Stefan Muenz]

Hallo Danie

Das Hauptproblem bei relationalen Datenbanken ist, eine hierarchische Struktur
wie sie Threads haben zu speichern.

Genaugenommen ist ein Forums-Thread ja von seiner Datenstruktur her gesehen eine Steilvorlage fuer den objektorientierten Ansatz mit integrierter Vererbungslehre. Nun gibt es zwar auch entsprechende, neuere Ansaetze im Datenbankwesen - eben objektorientierte Ansaetze anstelle relationaler Ansaetze. Aber da kenne ich mich nicht weiter aus ;-)

Und XML bildet die Vererbungsstruktur durch das Konzept der Elementverschachtelung zumindest datentypisch gesehen ideal ab. Man koennte also sagen: wir hier favorisieren eine den Daten optimal gerecht werdende Abbildung. Um die Performance haben wir uns dagegen bislang noch zu wenig Gedanken gemacht und haben Nachteile in Kauf genommen.

Aber abwarten ;-)

viele Gruesse
  Stefan Muenz

[Bio]

Sup!

Wenn obejektorientierte Datenbanken gleich einen ganzen Thread als Objekt anliefern, dann ist das schoen - aber es verdeckt nur, dass dann entweder bereits ein Treiber auf dem Client aus vielen vielen vom Server erhaltenen Datensaetzen das Objekt lokal zusammengesetzt hat, oder der Objekt-Server das Objekt vorher zusammengebaut hat. Die Objekte muessen ja irgendwie gespeichert werden, und zwar auf einem "flachen" Medium wie z.B. einer Festplatte, und da kommen dann wieder verkettete Listen und Indizes und Baeume zum Einsatz, womit man dann fast schon wieder bei den relationalen Datenbanken angekommen ist.
Bei den objektrelationalen Datenbanken ist das objektorientierte auf eine relationale Datenbank aufgepfropft.

Ich denke doch, die XML-Arbeitsweise des Forums ist eine Art Proof-of-Concept Sache, und nicht aus Notwendigkeit entstanden?

Gruesse,

Bio

[Martin Jung]

Hi,

aber es verdeckt nur, dass dann entweder bereits ein Treiber auf dem Client aus vielen vielen vom Server erhaltenen Datensaetzen das Objekt lokal zusammengesetzt hat,

Software "verdeckt" nur, dass Lösungen auf Hardwareebene durch Bit-Manipulationen erreicht werden.

oder der Objekt-Server das Objekt vorher zusammengebaut hat.

Irgendwann müssen Dinge/Objekte irgendwie generiert werden. Wie im richtigen Leben.
Ich glaube, entscheidend ist das Objektorientierte Konzept bei der Modellierung der Abbildungen und weniger wie und wann diese Objekte dann technisch erzeugt werden.

Die Objekte muessen ja irgendwie gespeichert werden, und zwar auf einem "flachen" Medium wie z.B. einer Festplatte, und da kommen dann wieder verkettete Listen und Indizes und Baeume zum Einsatz, womit man dann fast schon wieder bei den relationalen Datenbanken angekommen ist.

Objekte können auch direkt serialsiert werden. Verkettete Listen, Indizes und Bäume sind zum einen natürlich selbst Objekte, die zum anderen dazu verwendet werden, andere Objekte zu modellieren.

Viele Grüße,
Martin

[Bio]

Sup!

Objekte können auch direkt serialsiert werden. Verkettete Listen, Indizes und Bäume sind zum einen natürlich selbst Objekte, die zum anderen dazu verwendet werden, andere Objekte zu modellieren.

Nur liegen die Indizes und Listen, die z.B. die Stellen angeben, auf die die Objekt-Referenzen zeigen, das heisst, die Umsetzungstabellen von logischen auf physikalische Adressen, ausserhalb des Objektmodells des Objektes, das sie modellieren.

Gruesse,

Bio

[Daniela Koller]

Hi Stefan

Genaugenommen ist ein Forums-Thread ja von seiner Datenstruktur her gesehen eine Steilvorlage
fuer den objektorientierten Ansatz mit integrierter Vererbungslehre.

Ich verstehe nicht was du damit meinst, klar könnte man theoretisch Zitate aus
Vorgängerpostings vererben, aber was hat das mit objektorientierung zu tun?

Nun gibt es zwar auch entsprechende, neuere Ansaetze im Datenbankwesen - eben
objektorientierte Ansaetze anstelle relationaler Ansaetze. Aber da kenne ich mich nicht
weiter aus ;-)

Ich kann mir auch mit Objektorientierung keinen Weg vorstellen, ohne Rekursion auszukommen.

Und XML bildet die Vererbungsstruktur durch das Konzept der Elementverschachtelung zumindest »» datentypisch gesehen ideal ab. Man koennte also sagen: wir hier favorisieren eine den Daten
optimal gerecht werdende Abbildung. Um die Performance haben wir uns dagegen bislang noch zu
wenig Gedanken gemacht und haben Nachteile in Kauf genommen.

Genau das meine ich eigentlich, XML eignet sich perfekt für hierarchische Daten,
hingegen sind querverknüpte Daten eher mühsam darzustellen im Vergleich zu
relationalen Datenbanken welche dafür grosse Schwierigkeiten haben mit hierarchischen
Daten. Das einzige was XML noch fehlt (gibts in Ansätzen schon), ist ein sehr schneller
Zugriff wie das bei Datenbanken der Fall ist.

Gruss Daniela

[Martin Jung]

Hi,

Ich verstehe nicht was du damit meinst, klar könnte man theoretisch Zitate aus
Vorgängerpostings vererben, aber was hat das mit objektorientierung zu tun?

Kompositionsmuster. Die "Hauptdatei besteht" besteht aus einem Knoten (root = ein Objekt), Knoten haben Kinder (z.B. threads = Objekte), die sind selber Knoten und haben daher Kinder (z. B. Postings = Objekte).... Die generierte Datei ist selbst ein Objekt, eine FileObjekt.

Ich kann mir auch mit Objektorientierung keinen Weg vorstellen, ohne Rekursion auszukommen.

Was hat das (mathematisches Konzept) mit Objektorientierung zu tun?

Vie Grüße,
Martin

[Daniela Koller]

Hi Martin

Ich verstehe nicht was du damit meinst, klar könnte man theoretisch Zitate aus
Vorgängerpostings vererben, aber was hat das mit objektorientierung zu tun?
Kompositionsmuster. Die "Hauptdatei besteht" besteht aus einem Knoten (root = ein Objekt),
Knoten haben Kinder (z.B. threads = Objekte), die sind selber Knoten und haben daher Kinder
(z. B. Postings = Objekte).... Die generierte Datei ist selbst ein Objekt, eine FileObjekt.

Mir ist das Composite Pattern durchaus ein Begriff, in erster Linie ist das jedoch dazu
da, verschiedene Arten von Objekten die zusammenhängen können zu Speichern, das
ist aber hier nicht der Fall, da reicht auch ein einfacheres Konstrukt. Trotzdem
krieg ich das ganze nicht zusammen, ohne im entsprechenden Programm mit Rekursion zu
arbeiten, und das macht mir das ganze zu langsam.

Ich kann mir auch mit Objektorientierung keinen Weg vorstellen, ohne Rekursion
auszukommen.
Was hat das (mathematisches Konzept) mit Objektorientierung zu tun?

Mein Ziel ist es, ein Thread als ganzes auszugeben, und zwar ohne jedes
einzelne Posting fragen zu müssen, hast du Kinder, und gib mir die,
und genau das kann ich nicht ohne Rekursion... Ich kann mir keine
möglichkeit Vorstellen, Threads objektorientiert zu Speichern als ein
Haufen Postingobjekte die ihre Kinder kennen.

Zudem ist Rekursion ein Grundprinzip objektorientierter Programmierung.

Gruss Daniela

[Martin Jung]

Hi Martin

Mir ist das Composite Pattern durchaus ein Begriff,

Sollte nicht belehrend sein.

in erster Linie ist das jedoch dazu
da, verschiedene Arten von Objekten die zusammenhängen können zu Speichern,

Einspruch: Nach meinem Verständnis ist es ein Weg, die Realität (="zusammenhängende Objekte") _abzubilden_ bzw. zu modellieren.
Für mich ist es intuitiver, die Daten dieses Forums durch ein Object mit dem Namen "MessageTree" zu modellieren, welches dann genau über die Methoden verfügt, die ich ewarte: getRoot(), getParent(), getChild() etc..

Ich habe keinen "prozeduralen" Hintergrund. Ich denke, es ist mehr eine Frage der Denkweise. Technisch gesehen dürften sich die konkreten Implementierungen (Prozedur/Funktion vs. Methode) kaum unterscheiden.
Zumindest in Java werden für die Speicherung aus Performancegründen komplexe Objekte oftmals sogar "aufgebrochen", d.h. in ihre Teilobjekte zerlegt, und oft sogar nur deren primitiven Attribute/Datentypen persistent gemacht - in relationalen DBs.

das
ist aber hier nicht der Fall,

Wieso? Habe ich doch im vorigen Posting beschrieben.

da reicht auch ein einfacheres Konstrukt.

Was meinst Du mit "einfacheres Konstrukt"? Ich finde es einfach - weil naheliegend -, ein rekursives Problem rekursiv zu lösen.

Trotzdem krieg ich das ganze nicht zusammen, ohne im entsprechenden Programm mit Rekursion zu
arbeiten, und das macht mir das ganze zu langsam.

Ich meine nicht, das dieser Schluß der wichtigste einer Performanzanalyse ist. Da würde ich dann eher auf die Frage "XML ja oder nein?" kommen.

Mein Ziel ist es, ein Thread als ganzes auszugeben, und zwar ohne jedes
einzelne Posting fragen zu müssen, hast du Kinder, und gib mir die,
und genau das kann ich nicht ohne Rekursion...

Stimmt.

Ich kann mir keine
möglichkeit Vorstellen, Threads objektorientiert zu Speichern als ein
Haufen Postingobjekte die ihre Kinder kennen.

Die Frage bleibt, ob _das_ das lohnende Ziel für Performanzsteigerungen ist. Vielleicht wissen da andere mehr.

Zudem ist Rekursion ein Grundprinzip objektorientierter Programmierung.

Hmm, ich bin kein Informatiker, vielleicht liegt es ja daran. Aber: "Rekursion" habe ich noch nicht im Zusammenhang mit _Grundprinzipien_ objektorientierter Programmierung gelesen bz. gehört. Hast Du einen Link?

Viele Grüße,
Martin

[Daniela Koller]

Hi

in erster Linie ist das jedoch dazu
da, verschiedene Arten von Objekten die zusammenhängen können zu Speichern,
Einspruch: Nach meinem Verständnis ist es ein Weg, die Realität (="zusammenhängende
Objekte") _abzubilden_ bzw. zu modellieren.
Für mich ist es intuitiver, die Daten dieses Forums durch ein Object mit dem Namen
"MessageTree" zu modellieren, welches dann genau über die Methoden verfügt, die ich
ewarte: getRoot(), getParent(), getChild() etc..

Also ist der Thread für dich das Grouping Objekt, dann hätten wir die Hauptdatei
und als ein Grouping von Threads und Threads als ein Grouping von Postings das
sowohl ein Knoten als auch ein Grouping darstellt. Zusätzlich hast du aber noch
mehr Bedingungen die bei einem Composite Pattern nicht gegeben sind. Eine Hauptdatei
kann nur Threads beinhalten, jedoch keine Postings direkt. Genauso kann ein
Thread keine Hauptdateien beinhalten und ein Posting nur weitere Postings. Die
Struktur ist also nicht frei, sondern eindeutig hierarchisch in der wirklichen
Welt. Diese Einschränkungen können nicht so einfach mit dem Composite Pattern
abgebildet werden, resp, das fehlen dieser Beschränkungen führt bei sauberem
Design beinahe zwangsläufig zu diesem Pattern.

Zumindest in Java werden für die Speicherung aus Performancegründen komplexe Objekte
oftmals sogar "aufgebrochen", d.h. in ihre Teilobjekte zerlegt, und oft sogar nur deren
primitiven Attribute/Datentypen persistent gemacht - in relationalen DBs.

Java ist für mich keine saubere objektorientierte Sprache eben genau da sie
einen Unterschied macht zwischen Objekten und primitiven Typen.

Ganz genau diese Persistent ist das Problem, hier kommen Performanceprobleme
hinzu die nicht zu vernachlässigen sind bei einem Forum wie diesem, du
siehst ja selber wie gross diese Probleme bei diesem hier im Moment zumindest
teilweise sind. Das teuerste bei der Datenspeicherung ist nunmal der Zugriff
auf den Datenträger, deswegen sollte das so selten wie nur möglich geschehen.
Hätten wir nur Objekte ohne persistente Speicherung hätten wir damit keinerlei
Problem.

Wieso? Habe ich doch im vorigen Posting beschrieben.

Siehe oben Beschreibung der Datenstruktur mit den Einschränkungen was welche
Elemente beinhalten darf.

da reicht auch ein einfacheres Konstrukt.
Was meinst Du mit "einfacheres Konstrukt"? Ich finde es einfach - weil naheliegend -, ein rekursives Problem rekursiv zu lösen.

Ich sage nicht, das ein einfacheres Konstrukt nicht rekursiv arbeiten würde, es
hätte nur die Freiheit mit alles darf alles beinhalten nicht.

Trotzdem krieg ich das ganze nicht zusammen, ohne im entsprechenden Programm mit
Rekursion zu arbeiten, und das macht mir das ganze zu langsam.
Ich meine nicht, das dieser Schluß der wichtigste einer Performanzanalyse ist. Da würde
ich dann eher auf die Frage "XML ja oder nein?" kommen.

Das Performanceproblem bei Rekursion ist nur der reine Datenzugriff, viele
einzelne Files zu öffnen oder viele einzelne Male auf eine Datenbank zuzugreifen
ist viel aufwändiger als ein einzelner Zugriff auf eine grössere Datei. Der Zusatzaufwand
durch die Rekursion selber ist vernachlässigbar gering (Anlegen des Stacks,
Aufruf einer Funktion/Methode).

Ich kann mir keine
möglichkeit Vorstellen, Threads objektorientiert zu Speichern als ein
Haufen Postingobjekte die ihre Kinder kennen.
Die Frage bleibt, ob _das_ das lohnende Ziel für Performanzsteigerungen ist. Vielleicht
wissen da andere mehr.

Das Problem, abgesehen vom langsamen XML-Parser, ist meiner Meinung nach hauptsächlich das Öffnen vieler einzelner Dateien sowie die Locks darauf.

Zudem ist Rekursion ein Grundprinzip objektorientierter Programmierung.
Hmm, ich bin kein Informatiker, vielleicht liegt es ja daran. Aber: "Rekursion" habe ich »» noch nicht im Zusammenhang mit _Grundprinzipien_ objektorientierter Programmierung gelesen »» bz. gehört. Hast Du einen Link?

Link nicht, entsprechende Bücher lagere ich auch alle im Büro, ich kann mich da
nur an meine ersten Kurse in Objektorientiertem Softwaredesign erinnern.

Gruss Daniela

[Martin Jung]

Ho,

Also ist der Thread für dich das Grouping Objekt, dann hätten wir die Hauptdatei
und als ein Grouping von Threads und Threads als ein Grouping von Postings das
sowohl ein Knoten als auch ein Grouping darstellt. Zusätzlich hast du aber noch
mehr Bedingungen die bei einem Composite Pattern nicht gegeben sind. Eine Hauptdatei
kann nur Threads beinhalten, jedoch keine Postings direkt. Genauso kann ein
Thread keine Hauptdateien beinhalten und ein Posting nur weitere Postings. Die
Struktur ist also nicht frei, sondern eindeutig hierarchisch in der wirklichen
Welt. Diese Einschränkungen können nicht so einfach mit dem Composite Pattern
abgebildet werden, resp, das fehlen dieser Beschränkungen führt bei sauberem
Design beinahe zwangsläufig zu diesem Pattern.

Hmm. Soweit ich verstehe, wird das Composite-Pattern dazu verwendet, Teile-Ganzes-Hierarchien abzubilden und die Elemente uniform zu behandeln.
Letzteres natürlich nur da, wo es Sinn macht. Bei Implementierungen der konkreten Klassen müssen diese Besonderheiten/Einschränkungen berücksichtigt werden. Das heißt z.B., Root, Thread und Posting könnten weitere Konkretisierungen von Knoten sein. Ein Root hat keinen Parent und hat auch nur Kinder vom Typ Thread.
Das ist für mich eine Variation bzw. Implementierung des Kompositionsmusters.

Java ist für mich keine saubere objektorientierte Sprache eben genau da sie
einen Unterschied macht zwischen Objekten und primitiven Typen.

Hätte man dieses Design doch nur auch von Smalltalk übernommen...

Das teuerste bei der Datenspeicherung ist nunmal der Zugriff
auf den Datenträger, deswegen sollte das so selten wie nur möglich geschehen.
Hätten wir nur Objekte ohne persistente Speicherung hätten wir damit keinerlei
Problem.

?? Aber das ist doch kein Problem der OO, sondern ist unabhängig vom Programmierparadima, oder? Nichts spricht gegen Caching, selbst OO nicht.

Das Performanceproblem bei Rekursion ist nur der reine Datenzugriff, viele
einzelne Files zu öffnen oder viele einzelne Male auf eine Datenbank zuzugreifen
ist viel aufwändiger als ein einzelner Zugriff auf eine grössere Datei. Der Zusatzaufwand
durch die Rekursion selber ist vernachlässigbar gering (Anlegen des Stacks,
Aufruf einer Funktion/Methode).

Ich weiß nicht, wie das hier im Forum gelöst ist. Eine OO-Realisierung heißt aber nicht, dass ich Perfromanzfragen nicht Rücksicht nehmen müsste ;-)) Was spräche dagegen, die in XML persistent gemachten Daten im RAM zu cachen und nur auf diese Daten bei der Baumgeneration zuzugreifen?

Das Problem, abgesehen vom langsamen XML-Parser, ist meiner Meinung nach hauptsächlich das Öffnen vieler einzelner Dateien sowie die Locks darauf.

Davon habe ich nun gar keine Ahnung.

Viele Grüße,
Martin

[Daniela Koller]

Hi Martin

Java ist für mich keine saubere objektorientierte Sprache eben genau da sie
einen Unterschied macht zwischen Objekten und primitiven Typen.
Hätte man dieses Design doch nur auch von Smalltalk übernommen...

Volle Zustimmung, oder noch besser von Eiffel einem Smalltalknachfolger das zusätzlich
noch Design by Contract unterstützt.

Das teuerste bei der Datenspeicherung ist nunmal der Zugriff
auf den Datenträger, deswegen sollte das so selten wie nur möglich geschehen.
Hätten wir nur Objekte ohne persistente Speicherung hätten wir damit keinerlei
Problem.
?? Aber das ist doch kein Problem der OO, sondern ist unabhängig vom Programmierparadima, »» oder? Nichts spricht gegen Caching, selbst OO nicht.

Nein, das ist das Problem bei alle Problemlösungen die Rekursion verwenden. Auch
bei denen ohne, da allerdings nicht ganz so extrem da dann eben nicht so viele
einzelne Files / Datenbankzugriffe nötig wären sondern mit geschicktem Design
sehr viel weniger.

Ich weiß nicht, wie das hier im Forum gelöst ist. Eine OO-Realisierung heißt aber nicht,
dass ich Perfromanzfragen nicht Rücksicht nehmen müsste ;-)) Was spräche dagegen, die in
XML persistent gemachten Daten im RAM zu cachen und nur auf diese Daten bei der
Baumgeneration zuzugreifen?

Keinerlei Gründe, es ist halt einfach nur eine Option unter mehreren die erst
abgewogen werden müssen ob das drinliegt, ob genug RAM da ist...

Gruss Daniela

[Christian Kruse]

Hallo,

Nein, das ist das Problem bei alle Problemlösungen die Rekursion verwenden. Auch
bei denen ohne, da allerdings nicht ganz so extrem da dann eben nicht so viele
einzelne Files / Datenbankzugriffe nötig wären sondern mit geschicktem Design
sehr viel weniger.

Haettet ihr bloss den Source dieses Forums angeschaut. Dann haettet ihr gesehen,
dass die Forums-Hauptdatei gar nicht aus mehreren Dateien erstellt wird, sondern
dass die Threads ihrerseits in einer Index-Datei untergebracht sind. Diese
XML-Datei ist allerdings zwischendurch durchaus schonmal 200 oder 300KB gross.

Gruesse,
 CK

[Stefan Muenz]

Hallo Martin,

Was spräche dagegen, die in XML persistent gemachten Daten im RAM zu cachen und nur auf diese Daten bei der Baumgeneration zuzugreifen?

Hast du nicht Christians "pssst" vernommen? *g*

viele Gruesse
  Stefan Muenz

[Christian Kruse]

Hoi Stefan,

Was spräche dagegen, die in XML persistent gemachten Daten im RAM zu cachen und nur auf diese Daten bei der Baumgeneration zuzugreifen?

Hast du nicht Christians "pssst" vernommen? *g*

Nicht petzen! ;-))

Gruesse,
 CK

[Ed X]

Hi daniela,

Mein Ziel ist es, ein Thread als ganzes auszugeben, und zwar ohne jedes
einzelne Posting fragen zu müssen, hast du Kinder, und gib mir die,
und genau das kann ich nicht ohne Rekursion... Ich kann mir keine
möglichkeit Vorstellen, Threads objektorientiert zu Speichern als ein
Haufen Postingobjekte die ihre Kinder kennen.

auch auf die Gefahr hin, mich aufs Glatteis zubegeben, und hier etwas
falsch verstanden zu haben, aber es sollte IMHO auch ohne Rekursion
gehen und ohne das dem jeweiligen Vater seine Kinder bekannt sein müssen. Also was du speicherst ist im Prinzip eine Tabelle mit den
einzelnen Postings in der Reihenfolge ihrer Entstehung. Dazu
speicherst du für jedes Posting den Vater und daraus lässt sich sehr
schnell und ohne Rekursion ein Baum erstellen!

Zudem ist Rekursion ein Grundprinzip objektorientierter Programmierung.

kein einspruch.

by eddie
PS. Allerdings finde ich die XML Variante auch besser, da sie
Rechenaufwand vermindert und den Sever entlastet.

[Daniela Koller]

Hi

auch auf die Gefahr hin, mich aufs Glatteis zubegeben, und hier etwas
falsch verstanden zu haben, aber es sollte IMHO auch ohne Rekursion
gehen und ohne das dem jeweiligen Vater seine Kinder bekannt sein müssen. Also was du speicherst ist im Prinzip eine Tabelle mit den
einzelnen Postings in der Reihenfolge ihrer Entstehung. Dazu
speicherst du für jedes Posting den Vater und daraus lässt sich sehr
schnell und ohne Rekursion ein Baum erstellen!

Wonach sortierst du genau? Zuerst nach Thread, und dann?
Ich fände es schön wenn du eine Lösung findest das zu sortieren ohne
dass ein nachträglicher Sort nötig ist, aber ich weis keine Möglichkeit.

• Nach Stufe, das geht nicht, dann hat man nicht den Baum
• Nach Zeitpunkt geht auch nicht, der ist nicht eindeutig, ausserdem
    sagt der nichts aus über den Teilast des Postings
• Nach PostingID? Wie willst du die Vergeben das dass hinhaut ohne
    die Nachteile von Posting.Subposting...

Gruss Daniela

[Ed X]

Hi,

Wonach sortierst du genau? Zuerst nach Thread, und dann?

du hast eine Tabelle in die du die Poatings in der Reihenfolge ihres
erstellens reinschreibst, du speicherst weder die Anzahl der Kinder,
noch die Reihenfolge der Darstellung entsprechend der Hierarchie
sondern nur, auf welches Posting sich das aktuelle bezieht.
-1 bedeutet Threadursprung

Bezug | Titel | Postingzeit | Autor | Inhalt | .....
-1      bla      timestamp1   .....   .....    .....
 0      bla      timestamp2   .....   .....    .....
 0      bla      timestamp3   .....   .....    .....
 1      bla      timestamp4   .....   .....    .....
usw.

Daraus entsteht jetzt eine Baumstruktur und zwar nicht rekursiv.

wir hatten das schon mal:
http://forum.de.selfhtml.org/archiv/2001/11/1175/#m9209
das ist mit Sicherheit keine optimale Lösung, wie gesagt mir ist noch
keine bessere über den Weg gelaufen.

Wen man genau hinsieht, ist die Ermittlung der Hierarchie
(Einrücktiefe - blödes wort!) schon rekursiv. Sie lässt sich aber mit
dem Algorithmus zur Ermittlung der Reihenfolgen koppeln, was ich noch
nicht geschafft habe, da ich gerade Magisterarbeit Prüfung etc. am
brennen habe.

Prinzip der Ermittlung wäre folgendes: beim Aneinanderhängen der
Arrays müsste irgenwie "geloggt" werden, wie oft jedes einzele
Posting verschoben wird. Dieser Wert entspricht der hierarchischen
Ebene.

Im Prinzip ist es eine iterative Lösung für ein rekursives Problem.
Nur, iterative Lösungen sind meistens schneller ;-)

ICh hoffe du verstehst was ich meine und entschuldige, dass ich dir
diese Monsterposting zumute...

bye eddie

[Daniela Koller]

Hi Ed X

Bezug | Titel | Postingzeit | Autor | Inhalt | .....
-1      bla      timestamp1   .....   .....    .....
0      bla      timestamp2   .....   .....    .....
0      bla      timestamp3   .....   .....    .....
1      bla      timestamp4   .....   .....    .....
usw.

Daraus entsteht jetzt eine Baumstruktur und zwar nicht rekursiv.

verstehe ich das jetzt richtig, nachdem du alle Postings aus
der Datenbank geholt hast, musst du diese nochmal sortieren?

Mit nachträglichem Sortieren sind mir mehrere Lösungen bekannt,
nur ganz ohne Sortierung ausserhalb der Datenbankquery fällt mir
keine Lösung ein, auch bei deiner Art, die Postings abzulegen nicht.

Sonst, wie sieht die order by genau aus, ich sehe es echt nicht
wie du das damit ohne zusätzliche Sortierung lösen willst.

Das damit das Hauptproblem mehrerer Datenzugriffe gelöst ist,
sehe ich, nur du hast trotzdem eine nachgelagerte Sortierung

Gruss Daniela

[Ed X]

Hallo Daniela,

Bezug | Titel | Postingzeit | Autor | Inhalt | .....
-1      bla      timestamp1   .....   .....    .....
0      bla      timestamp2   .....   .....    .....
0      bla      timestamp3   .....   .....    .....
1      bla      timestamp4   .....   .....    .....
usw.

Daraus entsteht jetzt eine Baumstruktur und zwar nicht rekursiv.

verstehe ich das jetzt richtig, nachdem du alle Postings aus
der Datenbank geholt hast, musst du diese nochmal sortieren?

ja, darum kommst du bei relationalen systemen nicht drumrum (haltbare,
wenn acu nicht restlos beweisbare Annahme). Allerdings fällt es bei
dieser Lösung weg, die Väterpostings im nachhinein über Kinder zu
informieren.

Sonst, wie sieht die order by genau aus, ich sehe es echt nicht
wie du das damit ohne zusätzliche Sortierung lösen willst.

Es erzeugt einfach aus der logischen verlinkung eine Baumstruktur
wie hier im Forum, mehr nicht oder worauf willst du hinaus?

Das damit das Hauptproblem mehrerer Datenzugriffe gelöst ist,
sehe ich, nur du hast trotzdem eine nachgelagerte Sortierung

richtig, deshalb ist XML auch besser geeignet. Ich wollte nur sagen,
dass die Väterkinder nicht über ihre Kinder informiert sein müssen
und dass die Sortierung nicht rekursiv erfolgen muss. Ich sage auch
nicht dass der Ansatz sonderlich clever ist, schließlich wird zwar der
Zugriff auf die Datenbank verringert, allerdings zu Lasten der Pefor-
mance, die jedesmal beim Anzeigen gebraucht wird, während beim
Speichern fast gar nix gebraucht wird. Nur dummerweise wird ja mehr
gelesen als geschrieben, weshalb ich das ganze mittels Javascript
gelöst hab und die ganze Arbeit auf den Userrechner verlagert habe,
schwitzen soll er <eg>

bye eddie

[Christian Kruse]

Hoi,

Im Prinzip ist es eine iterative Lösung für ein rekursives Problem.
Nur, iterative Lösungen sind meistens schneller ;-)

Bitte was? Aufgrund welcher Annahme behauptest du das?

Gruesse,
 CK

[Ed X]

Moin,

Im Prinzip ist es eine iterative Lösung für ein rekursives Problem.
Nur, iterative Lösungen sind meistens schneller ;-)

Bitte was? Aufgrund welcher Annahme behauptest du das?

Ich könnte jetzt frech Henryk Plötz in seinem PHP-Forumsartikel
zitieren,...
http://aktuell.de.selfhtml.org/artikel/phpasp/php-forum/index.htm#a3
...aber einen sorgfältig formulierten iterativen algorithmus halte ich
deshalb für schneller, weil die Anzahl der Iterationen feststeht.
Bei einer Rekursion müss ähnlich einer while-schleife ein Abbruchs-
kriterium für jeden Durchlauf geprüft werden, also nochmal mit neuen
parameter(n) oder schluss. Sowas wirkt sich bei langen rekursionen
schonmal auf die performance aus.

bye eddie

[Frank Schönmann]

hi!

Nur, iterative Lösungen sind meistens schneller ;-)
Bitte was? Aufgrund welcher Annahme behauptest du das?
...aber einen sorgfältig formulierten iterativen algorithmus halte
ich deshalb für schneller, weil die Anzahl der Iterationen
feststeht.

Nö, das ist Quatsch... Die Laufzeit liegt bei rekursiven Lösungen in
der gleichen Effizienzklasse wie bei äquivalenten iterativen Lösungen,
nur ist die Speicherausnutzung bei iterativen Lösungen meistens
deutlich besser. Merke: Konstante Faktoren sind Schall und Rauch... :)

bye, Frank!

[Martin Jung]

Abend,

Moin,

...aber einen sorgfältig formulierten iterativen algorithmus halte ich
deshalb für schneller, weil die Anzahl der Iterationen feststeht.
Bei einer Rekursion müss ähnlich einer while-schleife ein Abbruchs-
kriterium für jeden Durchlauf geprüft werden, also nochmal mit neuen
parameter(n) oder schluss. Sowas wirkt sich bei langen rekursionen
schonmal auf die performance aus.

Meinst Du hier mit "Iteration" eine for-Schleife?

Ich dachte, es gilt generell:

Initialisierung;
while(*test*) {
  Anweisung;
  Inkrement;
}

ist äqivalent zu:

for(Initialisierung; *test*; Inkrement) {
  Anweisung;
}

Man muss (besser: sollte) generell bei _jeder_ Schleife für eine Terminierung sorgen, d.h. bei jedem Durchgang wird die Abbruchbedingung überprüft - genauso wie es in einer Rekursion gemacht wird. Ich dachte, das Performanzproblem bei Rekursionen ist vor allem auf die Verwaltung des wachsenden Stacks zurückzuführen.
Oder ich habe Fehler?

Viele Grüße,
Martin

[Frank Schönmann]

hi!

Oder ich habe Fehler?

Nö, das ist so ziemlich genau ganz richtig, oder so... ,)

bye, Frank!

[Ed X]

Abend,

Moin,

Abend, ;)

Meinst Du hier mit "Iteration" eine for-Schleife?

Ich dachte, es gilt generell:

Initialisierung;
while(*test*) {
  Anweisung;
  Inkrement;
}

ist äqivalent zu:

for(Initialisierung; *test*; Inkrement) {
  Anweisung;
}

eigentlich meinet ich das, aber wenn ich drüber nachdenke hast du
wohl recht

Man muss (besser: sollte) generell bei _jeder_ Schleife für eine Terminierung sorgen, d.h. bei jedem Durchgang wird die Abbruchbedingung überprüft - genauso wie es in einer Rekursion gemacht wird. Ich dachte, das Performanzproblem bei Rekursionen ist vor allem auf die Verwaltung des wachsenden Stacks zurückzuführen.
Oder ich habe Fehler?

selbst wenn es eine sache des speicher ist, sollte sich die iterative
formulierung lohnen, da eine optimierung der speicherperformance oder
wie auch immer man es nennen möge auch nicht ganz ohne sinn ist ;-)
was ich rekursiven lösungen aber zugestehn muss, sie sehen vielfach
einfach eleganter aus....

bye eddie,
der wohl nicht ganz so tief in der materie steckt

[Henryk Plötz]

Moin

Wonach sortierst du genau? Zuerst nach Thread, und dann?
Ich fände es schön wenn du eine Lösung findest das zu sortieren ohne
dass ein nachträglicher Sort nötig ist, aber ich weis keine Möglichkeit.

Ich weiss nicht ob du meinen Feature Artikel zu dem Thema schon kennst, aber ich verwende auch eine ähnliche Art um die Daten flach in einer MySQL-Datenbank abzulegen und das zeichnen dann von einer rekursiven Funktion erledigen zu lassen, ohne dass zu jedem Posting alle Kindpostings im entsprechenden Eintrag der Datenbank stehen müssen.

Ich speichere die Nummer des Vaterpostings bei jedem Eintrag in der Datenbank, sowie das Datum (wenn du dir nicht sicher bist, das das Datum bei deinem System immer gradeaus geht, musst du dir halt irgendwas anderes suchen, was garantiert in eine Richtung wächst) des Eintragens. Bei der Ausgabe der Hauptdatei (für einen Thread geht das analog) lese ich alle Betreffzeilen aus und lasse sie von der Datenbank nach Datum sortieren. Damit sind sie im Prinzip schon in der richtigen Reihenfolge bloß die Verschachtelung ist noch nicht klar.
Beim Auslesen in ein Array brauche ich ohnehin eine Schleife und in dieser Schleife konstruiere ich auch noch die Vorwärtsverknüpfungen indem ich in einem Array an der Position die der Nummer des Vaterpostings des aktuellen Postings entspricht (kriege ich ja aus der Datenbank) an ein weiteres Array die Nummer des aktuellen Postings anhänge. Die Kindpostings eines Vaterpostings sind jetzt ja automatisch in der richtigen Reihenfolge, weil sie so aus der Datenbank kamen und die Threadstruktur ist durch die Vorwärtsverknüpfungen wiedergegeben. Der Overhead für diesen Schritt ist minimal (zwei bis dreimal aus dem Hauptspeicher lesen und einmal reinschreiben).
Jetzt kann eine rekursive Funktion (oder meinetwegen auch eine iterative Funktion mit Kellerspeicher) den Baum ganz einfach zeichnen.

--
Henryk Plötz
Grüße aus Berlin

[Michael Schröpl]

Hi Daniela,

Wonach sortierst du genau? Zuerst nach Thread, und dann?
Ich fände es schön wenn du eine Lösung findest das zu sortieren ohne
dass ein nachträglicher Sort nötig ist, aber ich weis keine
Möglichkeit.

ich weiß nicht, ob Du Dir bei Deiner Darstellung einen Gefallen damit tust, "Rekursion" als etwas 'Böses' darzustellen.
Ich versuche mal, eine hinreichend exakte Aufgabenstellung zu dem zu erfinden, was hier die gante Zeit als Lösungsansätze diskutiert wird, insbesondere die zugrundeliegenden stillschweigenden Annahmen explizit zu formulieren und darauf basierend eine komplexitätstheoretische Bewertung der beiden Lösungsansätze abzugeben.

Was passiert denn eigentlich mit den zu verarbeitenden Daten, den Postings eines Forums?
Im wesentlichen haben wir es mit zwei Operationen zu tun:
a) Einfügung neuer Knoten (nachfolgend "Schreiben" genannt)
b) Ausgabe von Mengen von Knoten (Thread etc, nachfolgend "Lesen" genannt)

Für den allgemeinen Anwendungsfall stelle ich zwei Thesen auf:
1. Es werden wesentlich weniger Knoten pro Operation geschrieben (nämlich einer) als gelesen (eine entsprechende Granularität der Datenspeicherung vorausgesetzt - das leistet die "ein Thread = eine Datei"-Form von XML technisch bereits nicht mehr, eine relationale Datenbank mit record locking würde es können).
2. Es werden wesentlich mehr Lese- (viele pro Thread) als Schreiboperationen (eine pro Posting) durchgeführt.

Wenn wir zu beiden Aussagen entsprechende Faktoren bestimmen können (aus einer statistischen Analyse der konkret vorliegenden Daten), würden wir ein Verhältnis zwischen Leseoperationen (1 * 1) und Schreiboperationen (x * y) bestimmen können.
Die Gesamtkosten für die Verarbeitung wären in diesem Falle also
    (1 * Kosten_schreiben(n)) + (x*y * Kosten_lesen(n)),
wobei n die Menge der vorhandenen Daten beschreibt (hier die Anzahl Postings).

Irgendwie scheint dies nahezulegen, daß wir durchaus daran interessiert sein sollten, die Lesekosten niedrig zu halten, und zwar gerne auch auf Kosten höherer Schreibkosten.

Genau das leistet ein Indexbaum einer relationalen Datenbank im Vergleich zu einer sequentiellen Datenspeicherungsform (wie sie sowohl einer XML-Datei als auch der Archiv-Suche zugrunde liegt). Nehmen wir mal die Kostenrechnung für einen Suchvorgang:

• Bei der sequentiellen Anordnung sind die Kosten beim Schreiben in
    der Größenordnung O(1) - es wird genau ein Datensatz geschrieben.
    Die Kosten beim Lesen sind dagegen O(n) bei n Datensätzen, also
    linear.
• Bei der Indexstruktur ist das Schreiben viel teurer - jeder neue
    Datensatz muß in einen sortierten Baum eingefügt werden! Das kostet
    O(log (n)). Umgekehrt ist allerdings das gezielte Lesen sehr billig
    - über den Sortierungsbaum kann mit ebenfalls O(log n) jeder ge-
    wünschte Datensatz herausgesucht werden.
  Ehrlicherweise muß man dazu sagen, daß die Indexverwaltung einen gewissen Overhead kostet. Aber wie Frank völlig richtig sagte: "Lineare Faktoren sind Schall und Rauch" - denn bei einer Vervielfachung der Datenmenge werden sie sehr schnell irrelevant. Das ist auch der Grund, weshalb die sequentielle Suche mit O(n) bewertet wird - der implizite Faktor von 0.5 (im Mittel brauchen wir nur die Hälfte der Dokumente zu durchsuchen, um ein bestimmtes zu finden) fällt bei großen Datenmengen einfach hinter die Heizung.

Die obige Modell-Rechnung dürfte klar machen, was die Indexierung genau leistet: Sie verlagert die Kosten vom Lesen auf das Schreiben, _weil_ die Aufgabenstellung postuliert, daß sehr selten geschrieben, aber sehr häufig gelesen wird.

Im Prinzip macht Daniela mit ihrer gespeicherten Thread-Adressierung ("thread.posting.posting.posting" etc.) genau dasselbe: Sie baut eine Indexstruktur auf.
Denn diese Struktur wird ja nicht nur dazu genutzt, ein Posting innerhalb des Threads eindeutig zu adressieren - das Posting wird beim Schreiben bereits an der korrekt sortierten Stelle abgelegt.
Auch hier ist das Schreiben verteuert worden (und zwar genau wie oben von O(1) auf O(log (n)), während das Lesen eines sortierten Threads verbilligt wird, nämlich von O(n * log(n)) für das Lesen plus externe Sortieren auf nur noch O(n) für das Lesen der bereits sortiert abgespeicherten Postings.

Viele Grüße
      Michael

[Daniela Koller]

Hi Michael

Wonach sortierst du genau? Zuerst nach Thread, und dann?
Ich fände es schön wenn du eine Lösung findest das zu sortieren ohne
dass ein nachträglicher Sort nötig ist, aber ich weis keine
Möglichkeit.

ich weiß nicht, ob Du Dir bei Deiner Darstellung einen Gefallen damit tust, "Rekursion"
als etwas 'Böses' darzustellen.

Rekursion ist nicht grundsätzlich was böses, im Gegenteil, gewisse Probleme lassen
sich wunderschön mit Rekursion lösen, nur, wenn ich dadurch ausgerechnet das
teuerste am ganzen Problem, das lesen, im Vergleich zu einer anderen Lösung
(die immernoch Rekursiv sein kann, nur mit viel weniger Datenzugriffen), erheblich
häufiger durchführen muss, hab ich daran weniger Freude, und gerade der Connect
zu einer Datenbank ist sehr viel teurer als das eine programmmässige Sortierung
der relativ geringen, dh max einstelliger Tausenderbereich, Datenmenge. Zudem
würde die Sortierung eher aus einem Merge bestehen wo sowohl Ziel als auch
Quelle klar sind und aus zwei Stellen bestehen die sich nach unten verschieben
in einer Liste.

Ich möchte einfach wissen, ist es überhaupt möglich, ohne eben thread.posting.subposting...
ohne nachträglichen Merge oder Sortierung die Postings in der richtigen Reihenfolge
zu kriegen dass nur noch die Postingtiefe aufgrund von gehöre ich noch zum aktuellen
Vorgängerposting oder muss ich 1-n Stufen höher sein, ansonsten 1 tiefer.

Gruss Daniela

[Michael Schröpl]

Hi Daniela,

Ich möchte einfach wissen, ist es überhaupt möglich,
ohne eben thread.posting.subposting... ohne
nachträglichen Merge oder Sortierung die Postings in
der richtigen Reihenfolge zu kriegen dass nur noch
die Postingtiefe aufgrund von gehöre ich noch zum
aktuellen Vorgängerposting oder muss ich 1-n Stufen
höher sein, ansonsten 1 tiefer.

Stell Dir mal vor, Deine Thread-Darstellung sei kein beliebig breiter, sondern ein binärer Baum. Das läßt sich durch eine entsprechende Transformation jederzeit erreichen (die beiden Kinder eines Knotens sind dann die nächste Schwester und die erste Tochter; falls die Einfügung neuer Tochterknoten vorne statt hinten erfolgen soll, dann eben die vorherige Schwester und die letzte Tochter).

Und dann füge nacheinander Postings in den thread ein und berechne jedesmal deren Adresse in diesem binären Baum. Diese ist sowohl eindeutig (weil sie aus der Kombination aus Position und Entstehungshistorie abgeleitet wird und sich beides nie mehr ändert - neue Schwestern werden nur an einem definierten Ende der Liste eingefügt) als auch bereits sortiert (als binärer String).
Wenn Du über eine solchen Schlüssel einen Index legst, hast Du dieselbe Information wie durch Deine Punkt-Notation.
Einen Teil-Thread solltest Du in diesem Fall erhalten, indem Du
1. dessen Wurzel plus
2. alle Einträge mit einem Präfix-Match zum Schlüssels der ersten Tochter
selektierst. Die Sonderbehandlung des Wurzelknotens ist leider notwendig, weil der in keinem seiner beiden Teilbäume liegt - einer dieser beiden Teilbäume gehört zu diesem Teil-Thread, der andere aber nicht.

Du hast dann natürlich dieselben Probleme, welche der Datenbank-Indexer (der mit Deinen Punkt-Daten intern wahrscheinlich etwas ziemlich Ähnliches tun würde) auch hat:
1. Die Indexwerte können variabel lang werden.
2. Bei degenerierten Threads (Dialogen) wird der Baum zur Liste.
Und in dem von mir beschriebenen Fall ist die Adressierung exakt algorithmisch beschrieben - da ist kein Freiheitsgrad mehr, um den Baum on the fly zu rebalancieren.

Also: Ich sehe durchaus alternative Darstellungsmodelle für die sortierte Abspeicherung des Threads. Diese unterscheiden sich aber nicht wesentlich bezüglich ihrer Hauptprobleme.

Viele Grüße
      Michael

[Stefan Muenz]

Hallo Danie

Ich verstehe nicht was du damit meinst, klar könnte man theoretisch Zitate aus Vorgängerpostings vererben, aber was hat das mit objektorientierung zu tun?

Unter "ideal geeignet fuer objektorientierte Ansaetze" meine ich einfach, dass objektorientierte Ansaetze immer der Vorstellung einer Baumstruktur folgen. Und Threads haben eine Baumstruktur. Also scheinen sie fuer objektorientierte Ansaetze prima geeignet zu sein. (Kann natuerlich sein, dass dieser Syllogismus unerlaubt ist, aber in Logik war ich noch nie ne Leuchte ;-)

Ich kann mir auch mit Objektorientierung keinen Weg vorstellen, ohne Rekursion auszukommen.

Mit "objektorientierten Datenbanken" meinte ich natuerlich nicht DBs, die intern objektorientiert programmiert sind (das duerften wohl alle sein, die heute eine ernsthafte Rolle am Markt spielen). Ich meinte damit, dass die Datenhaltung in solchen DBs nicht mehr in verknuepften Tabellen erfolgt, sondern in Baeumen.

Eine Relation wie diese:
1. Name, Vorname, Strasse, Telefon, Personalnummer
2. Personalnummer, Kommenzeitpunkt, Gehenzeitpunkt

kann ja auch so ausgedrueckt werden:
Mitarbeiter
  Name,
  Vorname,
  Strasse,
  Telefon,
  Personalnummer
    Kommenzeitpunkt,
    Gehenzeitpunkt

In der zweiten Darstellung wuerde sich halt ergeben, dass irgendwann nach 10 eifrigen Dienstjahren ca. 2000 mal "Kommenzeitpunkt" und "Gehenzeitptunkt" unterhalb von "Personalnummer" steht. Es handelt sich gewissermassen um einen Datensatz "Mitarbeiter", der immer groesser wird und nicht, wie bei Tabellen, durch eine bestimmte Anzahl Felder begrenzt ist. Diese Form der Abbildung ist halt auch diejenige, die das Konzept von XML vorsieht. Und es gibt meines Wissens neuere Datenbanken, die ihre Daten ebenfalls in dieser Form halten. Sicher muessen solche DBs ebenso ihre Indizes verwalten wie relationale, wenn sie effizient und schnell arbeiten sollen. Ob sie dazu rekursive Methoden verwenden oder nicht, davon hab ich keine Ahnung. Aber das Datenmodell ist eben ein anderes. Ich bin aber sicher, Michael wird uns dazu noch eine Abhandlung schreiben, wenn er das hier entdeckt ;-)

Genau das meine ich eigentlich, XML eignet sich perfekt für hierarchische Daten, hingegen sind querverknüpte Daten eher mühsam darzustellen im Vergleich zu relationalen Datenbanken welche dafür grosse Schwierigkeiten haben mit hierarchischen Daten.

Was die Relationen betrifft, so sind diese finde ich durchaus durch Hierarchie ersetzbar, ohne dass man Informationsverluste hat. Siehe Beispiel oben. Was aber bei XML noch dazu kommt, ist die Moeglichkeit, eine unbestimmte und wechselnde Anzahl von Feldern zu definieren. Der eine Mitarbeiter ist meinetwegen in einer Gewerkschaft, der zweite ist vorbestraft, und der dritte hat schon mal einen wichtigen Auftrag vermittelt. Fuer all solche Sachen kann man problemlos mal in der DTD eines XML-Datenbestandes zusaetzliche, optionale Elemente definieren, die dann im Datenbaum eingefuegt werden koennen oder auch nicht. Tabellen sind in dieser Hinsicht meine ich einfach starrer - selbst bei optimaler Relationierung.

Das einzige was XML noch fehlt (gibts in Ansätzen schon), ist ein sehr schneller Zugriff wie das bei Datenbanken der Fall ist.

Jepp - und genau das wird glaube ich derzeit nicht nur hier bei uns erkannt. Nachdem nun genug dem XML-Gott gehuldigt wurde und die Leute nun tatsaechlich anfangen, mit XML-Anwendungen ihre Erfahrungen zu sammeln, kommt eben die Realitaet der Performance wieder ins Spiel - von solchen Dingen ist natuerlich in keiner W3-Spec die Rede.

Trotzdem halte ich den W3-Weg fuer richtig: erst sich Gedanken machen ueber die optimale Datenhaltung - und dann sagen: "tja, nun sind andere dran, die sich drum kuemmern sollen, wie man das akzeptabel schnell macht".

viele Gruesse
  Stefan Muenz

[Daniela Koller]

Hi Stefan

Was die Relationen betrifft, so sind diese finde ich durchaus durch Hierarchie ersetzbar,
ohne dass man Informationsverluste hat. Siehe Beispiel oben. Was aber bei XML noch dazu
kommt, ist die Moeglichkeit, eine unbestimmte und wechselnde Anzahl von Feldern zu
definieren. Der eine Mitarbeiter ist meinetwegen in einer Gewerkschaft, der zweite ist
vorbestraft, und der dritte hat schon mal einen wichtigen Auftrag vermittelt. Fuer all solche
Sachen kann man problemlos mal in der DTD eines XML-Datenbestandes zusaetzliche, optionale
Elemente definieren, die dann im Datenbaum eingefuegt werden koennen oder auch nicht.
Tabellen sind in dieser Hinsicht meine ich einfach starrer - selbst bei optimaler
Relationierung.

Ich meinte nicht das es nicht ginge, meine Bedenken sind in erster Linie Performanceprobleme
aus einer XML Datei krieg ich in einem Zug eine Baumstruktur heraus, hingegen mit SQL
krieg ich nicht ohne entweder Scriptseitige Sortierung / Merges, oder rekursion eine
Baumstruktur hin. Ausnahme hier sind eben neuere Konstrukte welche nicht Standardsql
sind und die gewisse Datenbanken wie Oracle bieten.

Deine speziellen Zusatzattribute welche freiwillig sind auch recht gut zu lösen mit
relationalen Datenbanken.

Trotzdem halte ich den W3-Weg fuer richtig: erst sich Gedanken machen ueber die optimale »» »» Datenhaltung - und dann sagen: "tja, nun sind andere dran, die sich drum kuemmern sollen, wie »» man das akzeptabel schnell macht".

Ich finde einen anderen Weg viel gefährlicher den viele gehen, nämlich, XML, oder relationale
Datenbanken, oder Objektorientierung ist ür alles geeignet, vielmehr ist alles von dem
nützlich für gewisse Anwendungen, nur halt jede hat Grenzen und Vorteile.

Gruss Daniela

[kerki]

Hallo !

Was die Relationen betrifft, so sind diese finde ich durchaus durch Hierarchie ersetzbar,
ohne dass man Informationsverluste hat. Siehe Beispiel oben. Was aber bei XML noch dazu
kommt, ist die Moeglichkeit, eine unbestimmte und wechselnde Anzahl von Feldern zu
definieren. Der eine Mitarbeiter ist meinetwegen in einer Gewerkschaft, der zweite ist
vorbestraft, und der dritte hat schon mal einen wichtigen Auftrag vermittelt. Fuer all solche
Sachen kann man problemlos mal in der DTD eines XML-Datenbestandes zusaetzliche, optionale
Elemente definieren, die dann im Datenbaum eingefuegt werden koennen oder auch nicht.

Ich glaube gerne, dass diese Datenstrukturbeschreibung für den Anwender leichter nachzuvollziehen ist, als eine wilde Ansammlung von 1:1, 1:n oder n:m Relationen zwischen x-und-zwanzig Datenbanktabellen.

Ich kann nur nicht glauben, dass ein auf XML-Dateien basierendes DBMS die Daten intern genauso verwalten kann ohne hinsichtlich der Performance hinter Lochstreifen ;-) zurückzufallen.

Tabellen sind in dieser Hinsicht meine ich einfach starrer - selbst bei optimaler
Relationierung.

Ich meinte nicht das es nicht ginge, meine Bedenken sind in erster Linie Performanceprobleme
aus einer XML Datei krieg ich in einem Zug eine Baumstruktur heraus , ...

Ich würde in diesem Punkt das genaue Gegenteil behaupten.

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?

Bei einem relationalen Tabellenansatz habe ich die Daten "pur" gespeichert und kann stelle die Hierarchie, Struktur, Relation, oder wie immer man es nennen will, quasi zum Zeitpunkt der Abfrage her. Flexibler geht's nimmer.

hingegen mit SQL
krieg ich nicht ohne entweder Scriptseitige Sortierung / Merges, oder rekursion eine
Baumstruktur hin. Ausnahme hier sind eben neuere Konstrukte welche nicht Standardsql
sind und die gewisse Datenbanken wie Oracle bieten.

Oracle kenne ich nicht (Geldbeutelproblem) aber solange es noch auf dem Relationalen Datenbankmodell beruht, ist damit eine Baumstruktur nicht zu machen. Ob nun das Datenbankmanagementsystem (Oracle) mir eine interne Programmfunktion zur Nachbildung einer Baumstruktur bietet oder ob ich mir diese selbst schreibe, ist letztlich auch relativ wurst (Programmierkenntnisse vorausgesetzt).

[...]

Trotzdem halte ich den W3-Weg fuer richtig: erst sich Gedanken machen ueber die optimale Datenhaltung - und dann sagen: "tja, nun sind andere dran, die sich drum kuemmern sollen, wie man das akzeptabel schnell macht".

Und ich behaupte rotzfrech: "Das geht nicht!" ;-)

Ich zitiere 'mal Martin von weiter oben im Thread:
"Natürlich hat XML-auch Nachteile. So kann das Verhältnis von Verwaltungsdaten (Element-Tags) zu Nutzdaten (Element-Daten) ungünstig werden, was Datentransferraten nicht unbedingt zum Vorteile gereicht."

Wenn ich mir dann noch überlege, dass - wenn schon, denn schon - auch die Datenbank-Index-Dateien in XML abgefasst sein müssten, rollen sich mir die Fußnägel hoch. ;-)

Ich finde einen anderen Weg viel gefährlicher den viele gehen, nämlich, XML, oder relationale
Datenbanken, oder Objektorientierung ist ür alles geeignet, vielmehr ist alles von dem
nützlich für gewisse Anwendungen, nur halt jede hat Grenzen und Vorteile.

Wenn ich dich hier richtig verstehe willst du sagen, für jeden Einsatzbereich gibt es ein spezialisiertes und optimiertes Datenformat. Dann stimme ich dir vollends zu.

Ich sehe die Zukunft für XML - wenn überhaupt - als standardisiertes Datenaustauschformat. Nicht mehr und nicht weniger.

Irgendjemand meiner Meinung? *hoff* :-)

Gruß,

kerki

[Martin Jung]

Hi,

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?

Wieso? Transformation mittels XSL/XSLT. Zu Performance sage ich da aber jetzt nichts ..

Wenn ich mir dann noch überlege, dass - wenn schon, denn schon - auch die Datenbank-Index-Dateien in XML abgefasst sein müssten

Wieso müssten? Ist das nicht Teil des internen Designs?

Ich sehe die Zukunft für XML - wenn überhaupt - als standardisiertes Datenaustauschformat. Nicht mehr und nicht weniger.

Irgendjemand meiner Meinung? *hoff* :-)

Um mal Herrn Schröder zu zitieren: Uneingeschränkt! Im Übrigen, wenn ich das noch hinzufügen darf, möchte ich "wenn überhaupt" durch "auf jeden Fall" ersetzen.

Viele Grüße,
Martin

[kerki]

Hallo !

[...] bin ich doch verraten und verkauft, oder nicht?
[...] Zu Performance sage ich da aber jetzt nichts ..

Ungefähr so wollte ich 'verraten und verkauft' verstanden wissen. ;-)

Wenn ich mir dann noch überlege, dass - wenn schon, denn schon - auch die Datenbank-Index-Dateien in XML abgefasst sein müssten
Wieso müssten? Ist das nicht Teil des internen Designs?

Kommt darauf an, was du mit 'intern' meinst. Sobald eine Speicherung auf einer Festplatte oder einem ähnlichen Speiermedium erfolgt, hieße das bei mir schon 'extern'. Ansonsten wäre entsprechend auch schon die Speicherung der tatsächlichen Daten eine interne Angelegenheit des DBMS (wogegen ich persönlich - wie man glaube ich heraushören konnte - nichts einzuwenden hätte).

Ich sehe die Zukunft für XML - wenn überhaupt - als standardisiertes Datenaustauschformat. Nicht mehr und nicht weniger.

Irgendjemand meiner Meinung? *hoff* :-)
Um mal Herrn Schröder zu zitieren: Uneingeschränkt!

Klingt wie "Ja, aber!". ;-(

Im Übrigen, wenn ich das noch hinzufügen darf, möchte ich "wenn überhaupt" durch "auf jeden Fall" ersetzen.

Dieses Jahr fangen die Koalitionsverhandlungen aber früh an! ;-)

Gruß,

kerki

[code2i]

moin

Ich zitiere 'mal Martin von weiter oben im Thread:
"Natürlich hat XML-auch Nachteile. So kann das Verhältnis von Verwaltungsdaten (Element-Tags) zu Nutzdaten (Element-Daten) ungünstig werden, was Datentransferraten nicht unbedingt zum Vorteile gereicht."

Sehr richtig. Eine alte HTML Site im XML Standart der neuen Generation ist super aufgeblasen. Alle reden immer von Traffic und Bandbreite aber XML knallt völlig dazwischen. Ich finde es eher sinvoll XML nur als eine "Erweiterung zu HTML" zu nutzen, so wie ich auch JavaScript als "Erweiterung" nutze.  Vorausgesetzt ich möchte auch anderen meine Daten in einer XML Struktur zur Weiterverarbeitung anbieten. (das glaub ich aber weniger)

Ich sehe die Zukunft für XML - wenn überhaupt - als standardisiertes Datenaustauschformat. Nicht mehr und nicht weniger.

Naja ! ich halte das ganze gerede von XML auch ein bischen aufgeblasen. Für manche Sachen ist es ganz brauchbar und nicht mehr wegzudenken, in anderen Bereichen ist wohl irgendwann der zaghafte Rückzug angesagt.

cu

[Michael Schröpl]

Hi,

Sehr richtig. Eine alte HTML Site im XML Standart der neuen Generation
ist super aufgeblasen. Alle reden immer von Traffic und Bandbreite
aber XML knallt völlig dazwischen.

an dieser Stelle plädiere ich einmal mehr für die Trennung der Zuständigkeiten. Wenn es um schnelle Datenübertragung geht, dann kann sich darum sehr wohl eine reine Übertragungsschicht kümmern - und genau das tut HTTP mit Content-Encoding ja auch.
Bei XML müßten also phantastische Komprimierungsraten drin sein.

Viele Grüße
      Michael

[Christian Kruse]

Hoi,

Trotzdem halte ich den W3-Weg fuer richtig: erst sich Gedanken machen
ueber die optimale Datenhaltung - und dann sagen: "tja, nun sind
andere dran, die sich drum kuemmern sollen, wie man das akzeptabel
schnell macht".

Und ich behaupte rotzfrech: "Das geht nicht!" ;-)

Na klar geht das. Was meinst du, wie schnell der Zugriff auf geparste
Strukturen im RAM ist?

Wenn ich mir dann noch überlege, dass - wenn schon, denn schon - auch die
Datenbank-Index-Dateien in XML abgefasst sein müssten, rollen sich mir die
Fußnägel hoch. ;-)

Das heisst nicht, dass sie jedesmal neu geparsed werden muessen. Das ginge
auch bei 'normalen' Index-Dateien nicht, vergiss es. Aber wieso nicht? Einmal
geparsed sind sie im Speicher -- von da an interessiert es eigentlich nicht,
wie das interne Format aussieht.

Gruesse,
 CK

[kerki]

Hallo !

Na klar geht das. Was meinst du, wie schnell der Zugriff auf geparste
Strukturen im RAM ist?

[...] Einmal geparsed sind sie im Speicher -- von da an interessiert es eigentlich nicht, wie das interne Format aussieht.

Auch 1 GB RAM geht irgendwann zur Neige, ebenso wie 54GB HDD, insbesondere bei entsprechend "platzverschwänderischer" Datenspeicherung mittels XML.

Wenn ich nicht völlig irre, geht es bei der Normalisierung von Daten vor allem darum, sich häufig wiederholende Daten durch Verteilung auf verschiedene Tabellen zu vermeiden. Wie sich dieser Grundgedanke mit dem Grundkonzept von XML mit seinen sich ständig wiederholenden Tags vertragen soll, ist mir komplett schleierhaft.

Zudem meine ich mich zu erinnern, dass derzeit für die Forumssuche - neben der XML-Speicherung der Threads - der gesamte Forumsinhalt noch einmal zusätzlich in einer CSV-Textdatenbank bereitgehalten wird.  Oder bin ich nicht mehr auf dem neuesten Stand der Dinge?

Gruß,

kerki

[Martin Jung]

Hi Kerki,

Auch 1 GB RAM geht irgendwann zur Neige, ebenso wie 54GB HDD, insbesondere bei entsprechend "platzverschwänderischer" Datenspeicherung mittels XML.

Aber das XML-Format dient doch nur der _externen_ Speicherung. Intern werden die Daten sinnvollerweise "anders" repräsentiert. Beispiel: Eine HTML-Datei wird in ein DOM transformiert.

Wenn ich nicht völlig irre, geht es bei der Normalisierung von Daten vor allem darum, sich häufig wiederholende Daten durch Verteilung auf verschiedene Tabellen zu vermeiden.

Wie sich dieser Grundgedanke mit dem Grundkonzept von XML mit seinen sich ständig wiederholenden Tags vertragen soll, ist mir komplett schleierhaft.

Wieso sollte er das? Ich bin mir auch nicht sicher, ob es bei Normalisierung primär um Performanzoptimierung (um Resourcenschonung sicherlichl) oder eher um Datenkonsistenz geht.

Ich würde die Lösung bevorzugen, die _insgesamt_ den besten Kosten/Nutzen-Ouotienten verspricht. Ich bin mir nicht sicher, ob für ein Forum wie dieses bei geeignetem Design einer DB-basierte Lösung zwangsläufigerweise zu subjektiv besserer Performanz führt. Die Resourcen, die die DB-Engine selbst konsumiert stehen z.B. für die XML-Logik zur Verfügung. Ich bin mir auch nicht sicher, welche Lösung mehr "WoManPower" für Design/Entwicklung/Pflege benötigt. Für flexibler halte ich das XML-Konzept in diesem Falle allemal.

Um Missverständnissen vorzubeugen: Bei "kritischen" (Business, Medizin etc.) Anwendungen würde ich natürlich DB-basierte Systeme favorisieren. Schon deswegen, weil mir die "großen" DBMS einem viel Arbeit abnehmen (Transaktionen, Zugriffsmanagement usw.).
In einem Projekt (Entwicklung eines Vollbanksystems) einer großen Bank wurden alle Schnittsetllen zwischen den Teilsystemen (Front-/Backend, Buchungssystem) vollkommen in XML realisiert. Natürlich kostet das Performanz (Stichworte: Transformation wie auch Transport der XML-Daten durch das Netz), erschien aber unter dem Strich deutlich attraktiver, da die Erweiterbarkeit des Systems stark vereinfacht werden konnte.

Es ist m.E. eine Frage der Abwägung, der eine umfangreiche(!) Analyse vorausgehen sollte.

Viele Grüße,
Martin

[Christian Kruse]

Hallo,

Auch 1 GB RAM geht irgendwann zur Neige, ebenso wie 54GB HDD,
insbesondere bei entsprechend "platzverschwänderischer" Datenspeicherung
mittels XML.
Aber das XML-Format dient doch nur der _externen_ Speicherung. Intern
werden die Daten sinnvollerweise "anders" repräsentiert. Beispiel: Eine
HTML-Datei wird in ein DOM transformiert.

Eben.

Wenn ich nicht völlig irre, geht es bei der Normalisierung von Daten vor
allem darum, sich häufig wiederholende Daten durch Verteilung auf
verschiedene Tabellen zu vermeiden.

Wie sich dieser Grundgedanke mit dem Grundkonzept von XML mit seinen
sich ständig wiederholenden Tags vertragen soll, ist mir komplett
schleierhaft.
Wieso sollte er das? Ich bin mir auch nicht sicher, ob es bei
Normalisierung primär um Performanzoptimierung (um Resourcenschonung
sicherlichl) oder eher um Datenkonsistenz geht.

Ich wuerde sagen, Datenkonsistenz. Denn es waere sicherlich schneller, wenn
die Daten nicht erst muehsam aus einer anderen Tabelle dazugeholt werden
muessen. Versteh mich nicht falsch, ich mag relationale Datenbanken :-)

Ich würde die Lösung bevorzugen, die _insgesamt_ den besten
Kosten/Nutzen-Ouotienten verspricht. Ich bin mir nicht sicher, ob für ein
Forum wie dieses bei geeignetem Design einer DB-basierte Lösung
zwangsläufigerweise zu subjektiv besserer Performanz führt.

Im momentanen Konzept denke ich das schon. In einem anderen Konzept
wahrscheinlich nicht mehr: wenn die XML-Daten geparsed im Speicher liegen,
wird eine DB wohl nicht mehr mithalten koennen.

Gruesse,
 CK

[Martin Jung]

Hi,

Im momentanen Konzept denke ich das schon. In einem anderen Konzept
wahrscheinlich nicht mehr: wenn die XML-Daten geparsed im Speicher liegen,
wird eine DB wohl nicht mehr mithalten koennen.

Man könnte ja auch für die DB-Daten lokale Proxies im RAM halten ..... ;-)

Viel Grüße,
Martin

[Michael Schröpl]

Hi Stefan,

Michael wird uns dazu noch eine Abhandlung schreiben, wenn er das hier entdeckt ;-)

Ach nee, gar nicht (vor allem, weil ich vom Innenleben 'richtiger' objektorientierter Datenbanken auch keine Ahnung habe - eigentlich würde es mich interessieren, aber irgendwie scheinen deren Hersteller den Internet-Crash voll abgekriegt zu haben, während die 'alten Hasen' wie Oracle und IBM das dank vorhandener Masse und geringerer Spezialisierung recht ordentlich aushalten).

Im Wesentlichen schließe ich mich Daniela an, daß beide Ansätze ihre deutlichen Vor- und Nachteile haben und daß es gefährlich ist, zu glauben, man könne mit einem Ansatz alle Probleme lösen. Ginge das, dann hätten wir heute beispielsweise nur eine Programmiersprache ...

Fuer all solche Sachen kann man problemlos mal in der DTD eines
XML-Datenbestandes zusaetzliche, optionale Elemente definieren,
die dann im Datenbaum eingefuegt werden koennen oder auch nicht.

Was ist daran flexibler, als eine zusätzliche Tabelle zu definieren und deren Inhalt bei Bedarf über einen gemeinsamen Schlüssel zu JOINen? Der wesentliche Unterschied ist m. E., daß Dir bei einer relationalen Datenbank die Zerlegung der Objekte ständig präsent ist, während Du bei XML in der Illusion lebst, alles sei sowohl geordnet als auch strukturiert - das mag ja semantisch der Fall sein, ignoriert aber in der Tat die Probleme der Realisierung.

Tabellen sind in dieser Hinsicht meine ich einfach starrer -
selbst bei optimaler Relationierung.

Eine 'richtige' relationale Datenbank würde für die zusätzliche Tabelle beispielsweise über Constraints eine kostenlose (praktisch kein Quelltext notwendig) und performante Wertemengenprüfung erlauben. Das geht bis zu Konstrukten, welche den Versuch des Entfernens eines Wertes der Wertemenge automatisch zurückweisen, wenn dieser Wert noch referenziert wird, oder sogar "delete cascading" machen, also alle abhängigen Werte automatisch mit entfernen.
Was Datenkonsistenz angeht, haben sich die relationalen Datenbanken schon mit einer ganzen Reihe von Problemen erfolgreich befaßt. Und das bezieht sich keineswegs nur auf Performance, sondern genauso auf Semantik.
Ich mag keine externen Anwendungen, welche sich mit der Konsistenz der Daten befassen - ich will "intelligente Daten"! Mit einer 'richtigen' relationalen Datenbank, insbesondere mit Constraints und Triggern und stored procedures, macht man die Datenmodellierung genau _einmal_, und die Anwendungsprogramme haben damit nichts mehr zu tun. (Vor allem kann auch keines davon mehr "pfuschen" und sich an irgendwelchen Prüfungen vorbei mogeln.) Von einer Objektdatenbank würde ich dasselbe verlangen.

Trotzdem halte ich den W3-Weg fuer richtig: erst sich Gedanken
machen ueber die optimale Datenhaltung - und dann sagen: "tja,
nun sind andere dran, die sich drum kuemmern sollen, wie man das
akzeptabel schnell macht".

Das ist die Vorgehensweise, die in den letzten Jahren in vielen Bereichen erfolgreich eingesetzt wurde: "Wir optimieren das jetzt nicht - bis das Produkt fertig ist, haben die Anwender ohnehin die nächste CPU-Version im Einsatz." Das mag prima gehen, wenn Faktor 2-5 fehlt.
Aber bei Datenbanken besteht einfach immer die Gefahr, einen logarithmischen durch einen linearen oder einen linearen durch einen quadratischen Faktor zu ersetzen. Und was das bei Datenmengen mit großen einstelligen Dezimalwerten bedeutet, kannst Du leicht ausrechnen - ein full table scan gegenüber einem Indexzugriff ist nur bei überschaubaren Datenmengen tolerierbar. (Das Forum-Archiv mit 10^6 Datensätzen ist da ungefähr der Grenzbereich, wie wir im praktischen Einsatz erleben - bei zehn- oder hundertmal so vielen Daten wäre die aktuelle Archivsuche nicht mehr brauchbar, über Indexzugriffe wären aber mehrere Zehnerpotenzen zu gewinnen.)
Wenn man da auch nur an _einer_ Stelle so richtig daneben greift, dann kann es so immens teuer werden, daß "geht nicht" durchaus die einzig meßbare Geschwindigkeit ist.

Ich halte Deinen Ansatz, zuerst die Semantik und dann die Performance zu betrachten, durchaus für richtig - nur solltest Du nie vergessen, daß das Anwendungsgebiet dafür entsprechend gefährlich ist und daß eine kleine, harmlose Änderung der Aufgabenstellung den Gesamtaufwand beträchtlich beeinflussen oder gar das existierende Datenmodell in Frage stellen kann.

Viele Grüße
      Michael

[kerki]

Hallo Stefan!

Das Hauptproblem bei relationalen Datenbanken ist, eine hierarchische Struktur
wie sie Threads haben zu speichern.

Genaugenommen ist ein Forums-Thread ja von seiner Datenstruktur her gesehen eine Steilvorlage fuer den objektorientierten Ansatz mit integrierter Vererbungslehre.

Kann ich gar nicht einmal finden, denn - andersherum betrachtet -besteht ein Forum aus massenhaft einzelnen Beiträgen, die alle die gleiche Struktur haben: Ein Thema, eine Überschrift, einen Autor, ein Erstelldatum und einen Nachrichtentext. -> Ein klassischer Fall für eine relationale Datenbank. ;-)

Und XML bildet die Vererbungsstruktur durch das Konzept der Elementverschachtelung zumindest datentypisch gesehen ideal ab. Man koennte also sagen: wir hier favorisieren eine den Daten optimal gerecht werdende Abbildung.

Ob du mit "ideal" und "optimal" so richtig liegst, wage ich zu bezweifeln.

Vermutlich ist, fernab von jeder Frage der technischem Umsetzung, auch sehr entscheidend, wie man die einzelnen Beiträge an sich gewichtet.

Nach der derzeitigen Datenstruktur wird ein Posting einzig als Unterobjekt eines Threads gesehen.

Genauso "wichtig" kann m.E. aber auch eine Einordnung nach dem Verfasser angesehen werden oder z.B. nach einem Themenbereich, der sich zu allem Übel innerhalb eines Threads grundlegend ändern kann.

Daher erscheint mir eine Struktur sinnvoller, die zunächst ein Posting als das ansieht, das es ist -> nämlich ein Posting unter vielen. Dies kann als Teil eines Threads betrachtet werden, muss es aber nicht.

Eine posting-bezogene Datenspeicherung wäre deutlich flexibler, und unter diesem Gesichtspunkt spricht dann auch nicht mehr viel gegen eine RDBMS-basierte Lösung. :-)

Gruß,

kerki

[kerki]

Hallo Daniela!

Mir geht es aber mehr um XML vs. DBMS (z.B. MySQL).

Das Hauptproblem bei relationalen Datenbanken ist, eine hierarchische Struktur
wie sie Threads haben zu speichern.

Stimmt!

Im Normalfall werden einfach alle Links gespeichert,
also Parent x, hat Kinder y,z ... Es ist kein Problem, jeweils alle
Kinderposting eines Parents rauszuholen, [...]
hingegen ist es mit Standard SQL
kaum möglich, bereits einen perfekt sortierten Baum aus der Datenbank zu kriegen
der bereits alle Angaben zur Einrückung enthält.

Unbestritten!

(Soviel ich weis, gibt es mit PL/SQL also Oracle, und uu auch PostgreSQL aber die Möglichkeit das zu lösen).

Kann sein, keine Ahnung!

Also muss pro Thread sozusagen für jedes Posting einzeln alle Kinder geholt
werden, und das ist sehr aufwändig weil jedesmal eine neue Anfrage an das
DBMS gestellt werden muss.

Angenommen, ich speichere zu jedem Beitrag die ID dessen Vaters und die ID des Ursprungspostings (Thread-ID), erhalte ich über eine DBMS-Abfrage alle Beiträge eines Threads und kann dann recht simpel in der mir zur Verfügung stehenden Programmiersprache anhand der Vater-IDs die Baumstrucktur nachbilden.

In etwa so, wie es Henryk in seinem Feature-Artikel beschrieben hat: http://aktuell.de.selfhtml.org/artikel/phpasp/php-forum/index.htm.

Es gibt hier zwar Möglichkeiten mit PostingIDs wie ThreadID.Posting.Posting.Posting...
zu arbeiten um die Hierarchie zu speichern, dafür muss die ID dann aber als
String gespeichert werden und von einem Script gemäss Punkten in dem String
richtig geparst werden, die Reihenfolgte stimmt jedoch schon direkt aus der
Datenbank

Im Zweifel führt diese Variante nur zu einer Einschränkung der möglichen Threadtiefe, da der benötigte String nicht endlos lang werden kann.

und ein aufwändiger Sortiervorgang ist nicht nötig.

Wo der von Henryk beschriebene Sortiervorgang 'aufwändig' ist, sehe ich nicht so ganz. Bei durchschnittlich (pi * Daumen) 20 Postings pro Thread dürften weder Perl noch PHP ins Schwitzen kommen.

Wie ist denn bisher die Datenhaltung per XML strukturiert? Habe ich aus dem bisher gesagten richtig herausgelesen, dass pro Thread ein XML-File angelegt wird?

Das würde zumindest erklären, warum man nur über Umwege auf einzelne Postings zugreifen kann. Die Message-Id ist ohne Thread-Id IMHO ja quasi wertlos.

Soweit richtig?

Gruß,

kerki

[Daniela Koller]

Hi

Wo der von Henryk beschriebene Sortiervorgang 'aufwändig' ist, sehe ich nicht so ganz. Bei
durchschnittlich (pi * Daumen) 20 Postings pro Thread dürften weder Perl noch PHP ins
Schwitzen kommen.

Jetzt stell dir das ganze nochmal der Hauptdatei dieses Forums vor, inklusive, wie
häufig das gemacht werden muss für die vielen Besucher dieses Forums...

Das ganze ist keinerlei Problem für kleine Datenmengen, und kleine Zahlen wie
häufig das gemacht werden müsste, auch rekursive Datenbankzugriffe sind kein
Problem bei kleinen Mengen an Zugriffen.

Gruss Daniela

[kerki]

Hallo!

Leider ist mir dein Text an entscheindenden Stellen etwas zu kurz und zweideutig formuliert. :-(

Wo der von Henryk beschriebene Sortiervorgang 'aufwändig' ist, sehe ich nicht so ganz. Bei
durchschnittlich (pi * Daumen) 20 Postings pro Thread dürften weder Perl noch PHP ins
Schwitzen kommen.

Jetzt stell dir das ganze nochmal der Hauptdatei dieses Forums vor, inklusive, wie
häufig das gemacht werden muss für die vielen Besucher dieses Forums...

Was genau soll ich mir vorstellen?

Ich habe keinen blauen Dunst, wie die jetzige Hauptdatei dieses Forums entsteht.

Wird da on-the-fly aus einer (mehreren) XML-Datei(en) serverseitig
eine HTML-Ausgabe generiert oder wird diese mit jedem neuen Posting statisch geschrieben?

Bei letzterem spräche nichts dagegen, dies auch weiterhin so zu handhaben und die Datenspeicherung entweder zusätzlich oder erst bei Eingang ins Archiv vorzunehmen. Bei ersterem habe ich keinen Schimmern, was schneller ist -> Eine oder zwei Datenbankabfragen mit Sortierung in Perl/PHP oder die serverseitig Generierung der Eingangsseite aus XML-Files.

Das ganze ist keinerlei Problem für kleine Datenmengen, und kleine Zahlen wie
häufig das gemacht werden müsste,

Welches "das ganze" meinst du jetzt? Die XML oder die SQL-Variante?

auch rekursive Datenbankzugriffe sind kein
Problem bei kleinen Mengen an Zugriffen.

BTW: Von rekursiven Datenbankzugriffen spricht außer dir kein Mensch. ;-)

Vielleicht kannst du mich ja 'mal kurz über meine Rückfragen aufklären.

Gruß,

kerki

[Christian Kruse]

Hoi,

Wird da on-the-fly aus einer (mehreren) XML-Datei(en) serverseitig
eine HTML-Ausgabe generiert oder wird diese mit jedem neuen Posting statisch
geschrieben?

Nein. Es gibt eine Index-XML-Datei, aus der die Hauptdatei generiert wird.

Gruesse,
 CK

[Michael Schröpl]

Hi Daniela,

Es gibt hier zwar Möglichkeiten mit PostingIDs wie
      ThreadID.Posting.Posting.Posting...
zu arbeiten um die Hierarchie zu speichern, dafür muss die ID dann
aber als String gespeichert werden und von einem Script gemäss
Punkten in dem String richtig geparst werden, die Reihenfolgte stimmt
jedoch schon direkt aus der Datenbank und ein aufwändiger
Sortiervorgang ist nicht nötig.

Das ist jetzt die Stelle, wo die theoretische Modellierung auf die Realität trifft. Denn genau das ständige Parsen der Strings möchte man an dieser Stelle dringend vermeiden - der Thread soll bereits sortiert abgespeichert werden.

Also muß der "Pfad" des Postings ein sortierbarer Schlüssel sein. Das ist im Falle der obigen Darstellung aber nur dann der Fall, wenn
a) die "Spalten" voneinander getrennt angesprochen werden oder
b) die "Spalteninhalte" durch Werte gleicher Länge dargestellt werden.

Fall a) wäre ganz gruselig - wir wollen ja ganz bestimmt keine Datenstruktur haben, welche pro Thread-Tiefe eine Tabellenspalte verbrät (erstens limitiert das 'hart' die mögliche maximale Tiefe eines Threads, zweitens kostet es massenhaft Platz).

Fall b) wäre schon eher machbar, aber auch nur unter Randbedingungen.
Nehmen wir mal an, wir hätten eine festgelegte Maximalzahl von Sohn-Knoten pro Verzweigungstiefe, welche aufgrund einer Analyse des Datenmaterials erschlossen werden kann - wir hatte noch nie mehr als (beispielsweise) 47 Antworten auf derselben Ebene, also wird 99 eine Einschränkung sein, die niemandem wirklich weh tut. In diesem Falle wäre jede Posting-Bezeichnung als String aus zwei Ziffern darstellbar, und der gesamte String wäre sortierbar. (Mit etwas mehr Übersetzungsaufwand läßt sich natürlich dieser Mini-Integer in ein Byte codieren und aus der Folge der Posting-Bezeichner ein Binär-String konstruieren, welcher dieselbe Sortierbarkeits-Eigenschaft besitzt, mehr Werte darstellen kann und halb so viel Platz kostet.)
Trennzeichen zwischen den Ebenen brauchen wir dann natürlich keine.

Was wir immer noch bräuchten, wäre eine maximale Thread-Tiefe. Allerdings nicht als harte Grenze, sondern möglicherweise nur als weiche.
'Viele' Threads werden eine bestimmte Tiefe nicht überschreiten - raten wir mal eine Tiefe, die für 70-85% der Threads ausreichen würde, und reservieren den Platz für entsprechend lange sortierbare Thread-Schlüssel. (Über die uns im Wesentlichen bekannte Verteilungsfunktion der Thread-Tiefen wissen wir gleichzeitig, wieviel Luft wir in diesem Indexbaum mitschleppen.) Was aber tun, wenn jemand einen tieferen Thread erzeugt? Nun, niemand zwingt uns dazu, eindeutige Schlüsselwerte zu verwenden! Das heißt: Ab einer bestimmten Tiefe des Threads werden alle Postings denselben Schlüsselwert haben - und wir werden auf Anwendungsebene nachsortieren müssen. Such is life - es liegt an den vorhandenen Ressourcen, ob dieser Effekt in nennenswert vielen oder nur in ganz wenigen Fällen zum Tragen kommen wird.
(Nichts wesentlich Anderes liegt der Idee zugrunde, eine Phrasensuche mit einer Indexsuche und nachgeschaltetem Filter zu realisieren.)

Letzten Endes wäre meine bevorzugte Implementierungsmethode also womöglich gar ein Hybrid-Modell zwischen ganz verschiedenen Darstellungstechniken. Den Trade-Off zwischen den Vor- und Nachteilen zweier Ansätze würde ich versuchen, zu lösen, indem ich das mir genehmere Verfahren in den meisten Fällen und das alternative in den abstrusen Sonderfällen zum Einsatz bringe.
Um so sorgfältiger muß ich natürlich vorher die anfallenden Daten kennen - denn wenn am Ende das weniger performante Modell in 70% der Fälle zum Einsatz kommt, dann hat die Lösung ihre Aufgabenstellung verfehlt ...

Viele Grüße
      Michael

[Martin Jung]

Hi Michael,

wer analysieren kann, ist klar im Vorteil ;-)

Wenn wir zu beiden Aussagen entsprechende Faktoren bestimmen können (aus einer statistischen Analyse der konkret vorliegenden Daten), würden wir ein Verhältnis zwischen Leseoperationen (1 * 1) und Schreiboperationen (x * y) bestimmen können.

Warum (1 * 1) zu (x * y) und nicht 1 zu x (1 Schreiboperation auf x Leseoperationen)? Der resultierende Quotient stellt nach meinem Verständnis doch bereits ein mögliches Maß für eine Gewichtung dar. Warum multiplizierst Du hier zusätzlich?

Irgendwie scheint dies nahezulegen, daß wir durchaus daran interessiert sein sollten, die Lesekosten niedrig zu halten, und zwar gerne auch auf Kosten höherer Schreibkosten.

Die textuelle Erklärung leuchtet mir ein ;-)

Genau das leistet ein Indexbaum einer relationalen Datenbank im Vergleich zu einer sequentiellen Datenspeicherungsform (wie sie sowohl einer XML-Datei als auch der Archiv-Suche zugrunde liegt). Nehmen wir mal die Kostenrechnung für einen Suchvorgang:

• Bei der sequentiellen Anordnung sind die Kosten beim Schreiben in
    der Größenordnung O(1) - es wird genau ein Datensatz geschrieben.

O(1), weil Du 1 Schreibvorgang zu n Lesevorgängen in Beziehung setzt?

Die Kosten beim Lesen sind dagegen O(n) bei n Datensätzen, also
  linear.

• Bei der Indexstruktur ist das Schreiben viel teurer - jeder neue
    Datensatz muß in einen sortierten Baum eingefügt werden! Das kostet
    O(log (n)). Umgekehrt ist allerdings das gezielte Lesen sehr billig
    - über den Sortierungsbaum kann mit ebenfalls O(log n) jeder ge-
    wünschte Datensatz herausgesucht werden.

Was ist der Unterschied zwischen O(log (n)) und O(log n)? - keine Steinigung bitte ;-)

...... Aber wie Frank völlig richtig sagte: "Lineare Faktoren sind Schall und Rauch" -

Sagte er nicht: "Konstante Faktoren sind Schall und Rauch"?

Viele Grüße,
Martin

[Michael Schröpl]

Hi Martin,

Warum (1 * 1) zu (x * y) und nicht 1 zu x (1 Schreiboperation auf x Leseoperationen)? Der resultierende Quotient stellt nach meinem Verständnis doch bereits ein mögliches Maß für eine Gewichtung dar. Warum multiplizierst Du hier zusätzlich?

Weil ich klar machen möchte, daß der Faktor _deutlich_ größer ist als 1.

O(1), weil Du 1 Schreibvorgang zu n Lesevorgängen in Beziehung setzt?

Ich berechne in beiden Fällen die Kosten in Abhängigkeit von der Zahl der durchgeführten Operationen. Ich glaube, mit den Variablennamen bin ich an der einen oder anderen Stelle nicht wirklich exakt umgegangen - x und y habe ich erst beim Korrekturlesen eingeführt, um sie von n abzugrenzen. (Für eine Seminararbeit hätte ich sicherlich sorgfältiger arbeiten müssen als für einen Forums-Beitrag.)

Was ist der Unterschied zwischen O(log (n)) und O(log n)? - keine Steinigung bitte ;-)

Ich schreibe Funktionsaufrufe immer mit runden Klammern (auch in Perl, wo das nicht notwendig wäre), und ich halte 'log' in diesem Kontext für eine Funktion.

...... Aber wie Frank völlig richtig sagte:
"Lineare Faktoren sind Schall und Rauch" -
Sagte er nicht: "Konstante Faktoren sind Schall und
Rauch"?

Ups - sorry.

Bei komplexen Operationen komme ich praktisch nie unterhalb von O(n) weg (die Darstellung der kompletten Hauptdatei ist beispielsweise eine Sortierung _aller_ Threads und damit etwa O(n * log (n)), und in diesem Kontext wären sogar lineare Faktoren weniger wichtig, nicht nur konstante.

Viele Grüße
      Michael

[Martin Jung]

Hi,

Vielleicht erklärt mir ja 'mal jemand in groben Zügen, welche Vorteile XML gegenüber anderen Techniken im Allgemeinen und hinsichtlich beispielsweise einem Einsatz für ein Forum im Speziellen überhaupt hat.

Mal so auf die "Schnelle":

Allgemein: Standardisierung. Standards sind immer gut. Vereinfachen Design/Implementierungen kolossal.

Spezieller: XML kann zum einen als standardisiertes _abstraktes_ Daten-Format betrachtet werden, dessen Struktur sich einem auch auf ASCII-Ebene sofort erschließen kann (Transparenz). Daraus ergibt sich dann zwangsläufig ein generisches Datei-Format. Die Möglichkeit, die Gültigkeit der XML-Daten zu validieren (gegen DTDs), stellt weiterhin einen allgemeinen Mechanismus zur Prüfung der Daten auf Korrektheit (Struktur, Inhalt etc.) da.

Man kann  mit Hilfe der DTDs _beliebige_ Dokumenttypen definieren.
Beispiele: XHTML, SVG. Oder SOAP, ein XML-basiertes Protokoll für entfernten Prozeduraufruf (a la CORBA, COM etc.). Oder Web-Services (WSDL), bei welchen die Server ihre verfügbaren "Service-Applikationen" in Form von XML-Dokumenten veröffentlichen.

Für all diese "Anwendungen/Formate" benötigt man genau eine Implementation eines (validierenden) XML-Parsers. D.h. keine speziellen Im-/ oder Exportfilter sind notwendig. Um die dahinterhängende Logik muss man sich ja natürlich immer noch selber kümmern..

Natürlich hat XML-auch Nachteile. So kann das Verhältnis von Verwaltungsdaten (Element-Tags) zu Nutzdaten (Element-Daten) ungünstig werden, was Datentransferraten nicht unbedingt zum Vorteile gereicht.

Viele Grüße,
Martin

[Thomas J.S.]

hallo kerki,

Andersherum fielen mir reichlich Dinge ein, die mit DBMS-gestützter Datenhaltung besser oder einfacher zu machen wären.

nämlich?

»»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!

Nur zur Sicherheit: Ich will nicht meckern! Die hier eingesetzte Forensoftware ist toll! Glaube ich zumindest. Auf meinem heimischen Server habe ich sie allerdings mangels ausreichender Perl-Kenntnisse und vorhandener Dokumentation nicht ans Laufen bekommen.

ich habe auch keine perlkentnisse, aber ich habe es hinbekommen (wie wohl ich vermerken muss, dass irgendwo ein fehler in den dateien auf sourceforge.net gab.

Mir geht es aber mehr um XML vs. DBMS (z.B. MySQL).

Aus meiner derzeitigen Sicht ist XML  schlichtweg der größte Mumpitz seit Erfindung des Computers.

tja, genau das haben leute über den computer gesagt. es passt als bestens zusammen.

Vielleicht erklärt mir ja 'mal jemand in groben Zügen, welche Vorteile XML gegenüber anderen Techniken im Allgemeinen und hinsichtlich beispielsweise einem Einsatz für ein Forum im Speziellen überhaupt hat?

wozu? du willst dich doch nicht mit Mumpitz befassen??

----- zitat ---
Daher erscheint mir eine Struktur sinnvoller, die zunächst ein Posting als das ansieht, das es ist -> nämlich ein Posting unter vielen. Dies kann als Teil eines Threads betrachtet werden, muss es aber nicht.
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. klar du kannst die info die du suchst in einem einzigen posting finden, aber oft ist die umgebung ebenso notwendig für das verständniss. und wenn du dabei nur tausende von einzelpostig hast, bist du gelindegesagt aufgeschmissen.

(vergleich bibliothek: regale auf regale auf regale voll mit büchern (einzelpostings), wenn du jetzt etwas suchst findest du zwar das buch (posting), aber wenn in dem buch auf ein anderes buch zum selben thema bezug genommen wird, hast du probleme das andere buch (einzelposting) zu finden, es sei denn das andere buch (posting) liegt direkt neben deinem buch unter dem themenkreis (thread) das dich interessiert. und genau dieses hierarchische prinzip wird bei bibliotheken verfolgt)

----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.
ich frage mich eigentlich warum leute sich immer wieder und nur an der performance anecken, wohl sonst keine andere argumente gegen xml!?
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.
hier redet jeder von professionellen DBs und dann von unserem hausgemachten forum mit eingenen perl-parser etc.

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)

----
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. :-)

dagegen bietet xml nicht nur eine struktur in der das was zusammengehört auch zusammen ist an, sondern ermöglich es mir mit wenigen mitteln die mehrfachverwendung der informationen.
klar ist xml auch ein austauschformat (siehe eben .net und webservises) aber das ist nur eine kleinigkeit.

aber es genügt, du willst ja vom Mumpitz eh nichts wissen. oder?

grüße
thomas

Viele Grüße
  Andreas

[kerki]

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

[Michael Schröpl]

Hi kerki,

kannst du dort aus der DB alle gewünschten
formate so super schnell erzeugen? das wäre
mir was ganz neues.
Theoretisch zumindest: ja!

Vorausgesetzt, ich investiere in die entsprechende Infrastruktur. (Siehe hierzu meine aktuellen Beiträge an anderer Stelle; suche nach "Daniela" als Thread-Kontext, das hilft.)

Für mich sind Performance ein _enorm_ wichtiges
Argument. Daher würde es mir als einziges
Gegenargument schon reichen.

Full Ack.
(Ich re-implementiere gerade eine Suchmaschine mit dem ausschließlichen Ziel, zehnmal so viele Daten mindestens fünfmal so schnell durchsuchen zu können wie  mein Vorgänger, der in etwa das tut, was auch die Self-Suchmaschine macht, nur ohne deren _sämtliche_ Formular-Optionen ...)

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.

Die 'CSV-Datei' ist viel älter als die XML-Struktur.
Schon zu Zeiten der Gründung des ersten Forum-Archivs hat sich Stefan Münz, der Autor des Schwanzabschneiders, für eine Vorverarbeitung der zu durchsuchenden Daten entschieden - aus der m. E. völlig richtigen Idee heraus, daß es doch ausreicht, diese Vorverarbeitung erstens nur ein einziges Mal und zweitens nicht während der Wartezeit des Anwenders, sondern irgendwann vorher durchzuführen.
Genau dasselbe Prinzip liegt der Idee der Datenbank-Indexe zugrunde - "index once, search anytime".

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.

Dem schließe ich mich an - darüber würde ich auch gerne etwas lernen wollen.

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! :-)

Ehrlich, ich verstehe Euch beide sehr gut.

Einerseits kann ich mit vielen Tabellen und komplexen JOINs prima leben, weil das nun mal die Denkweise eines relationalen Entwurfs ist - man zerlegt seine Daten eben in Objekte und Beziehungen zwischen den Objekten.

Andererseits verstehe ich auch, daß klassisches SQL eine Gruppierung dieser Objekte nur sehr mäßig unterstützt. Insofern finde ich die (für mich als alter Oracle7-Anwender zunächst völlig neue) Idee von mySQL, die Daten in viele separat benannte Datenbanken zu unterteilen (vorher war für mich eine Datenbank etwas, das von einem RDMBS betrieben wird, und umgekehrt, also 1:1, nicht n:1) und damit semantische Zusammengehörigkeiten zumindest besser zu dokumentieren, wirklich hilfreich.

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.

Ich denke, dieser Punkt zeigt vielleicht am besten, daß beide Darstellungsformen unterschiedliche Ziele zu erreichen versuchen: XML konzentriert sich eben auf diese eine Strukturform, während bei Relationen die Gleichwertigkeit beliebig vieler Zusammengehörigkeiten oberstes Prinzip ist.
Deshalb kann man in SQL mit verschiedenen Queries wirklich sehr elegant verschiedene "Sichtweisen" auf dieselben Daten gestalten - und diese noch dazu in Form von Views dauerhaft in der Datenbank abspeichern (und einem Anwender anderer Abfragen sogar weitgehend den Unterschied zwischen Tabellen und Views verheimlichen).

Viele Grüße
      Michael

[Thomas J.S.]

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?

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.

welche 3?
1)Statistiken, 2) Querverweise, 3) ??

Es besitz ein jeder Message eine unique ID. 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.  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.

beides sind ohne MySQL möglich. mit XSLT kann ebenso jedes beliebige Detail eines Thread oder Messages gefiltert werden.
Wieso beides? Auf meinen dritten und vielleicht wichtigsten Punkt bist du gar nicht eingegangen.

wenn du die ID meinst, siehe weiter oben.

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 delata- und und für "titel" im gamma-quadrant)

(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 mit einer DB wir 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)

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?

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?

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.

es wurden hier schon mehrere gegenargumente genannt, angfangen von der hierarchischen struktur, bis hin zu plattform und software unabhängigen möglichkeit von datenaustausch.

übrigens, wenn DB an sich doch so toll ist, warum arbeiten so sehr die DB hersteller an der XML unterstützung ihrer DBs?

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.

http://forum.de.selfhtml.org/archiv/2002/1/2538/#m14419

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. hätten wir das geld, würde ich sofort eine xml-db einsetzen wollen und dann kümmert mich kein csv-datei mehr.

Ich hoffe, du nimmst mir nicht übel, dass ich von Tamino noch nie etwas gehört habe.

tamino ist der xml-server vom software AG.
der textml, tamino und excelon sind die zur zeit führenden xml-server auf dem markt.

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*

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)

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

was tabellen in einer DB angeht:
ist ja ekelhaft. :-)

Schlag mich tot: Ich find's toll! :-)

Sancta simplicitas!! :-þ

grüße
thomas

[kerki]

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

[Thomas J.S.]

Hallo Kerki,

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.

zweierlei:
was du hier als UID genommen hast ist nur die message nummer.
darüber hinaus haben hier im der index.xml alle messages eine UID.
(in den einzelnen threads-dienen dann die meeage nummer als ID)

aber du hast hier eine URI genommen. unud wenn du die ichtige URI nimmst dann funktioniert. und wenn du in einer DB falsch suchst bekommst du dort auch keine suchergebnisse.
aber wie gesagt: die möglichkeiten sind ja da!
siehe eben das ARchiv:
http://forum.de.selfhtml.org/archiv/2002/1/2538/#m14419

ich kann mir nicht vostellen, dass du ein einer DB anders machen würdest als durch einen "Pfad" zu suchen...oder muss in einer DB immer das gesamte datenbestand durchgesucht werden?

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.

das ist eben das plus an den links! willkürlich ist natürlich ein schöner ausdruck für "frei definierbare" ;-)

es wäre auch sowas möglich:
http://forum.de.selfhtml.org/archiv/2002/1/2538.xml#xpointer(id('m14419'))

für:
http://forum.de.selfhtml.org/archiv/2002/1/2538/#m14419

oder:
http://forum.de.selfhtml.org/archiv/2002/1/2538.xml#xpointer(id('m14419')/string-range(Author/Name,"fjh"))

oder
http://forum.de.selfhtml.org/archiv/2002/1/2538.xml#xpointer(id('m14419')/Author/Name)

würde fjh zurückliefern

oder:
http://forum.de.selfhtml.org/archiv/2002/3/5782.xml#xpointer
string-range(//MessageContent,"Mumpitz")[1]

könne eines tages auf das erste vorkommen von "Mumpitz" in diesem thread hinlinken, ohne dass ich dafür 100-e von tabellen durchsuchen müsste!

wie gesagt: all diese möglicckeiten sind schon gegeben, es ist bloß eine frage der zeit bis die entsprechende software da ist.

Statt 'überreif' hätte ich lieber 'ausgereift' gehört. ;-(

ich weiss, ich wollte eigentlich was schlimmeres sagen, aber mir ist nichts eingefallen was zwar schlimm, aber noch keine beleidigung ist *g*

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.

das mit dem überblick geht mir genau so! ;-)

Es ist ja nun nicht so, dass in einem relationalem Datenmodell die Bezüge zum Context nicht auch erhalten blieben.

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.

ich sehe bloß keinen einzigen vernünftigen grund, warum ich das was zusammengehört erts in zig tabellen aufteilen muss/soll nur um später mühsamst wieder alles zusammenzufügen wenn ich es brauche.

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...

sehr einfach gesagt: RFD beschreibt recourcen in subjekt-prädikat-objekt form. simple katalogzettel in der bibliothek:
"tolkien" - "ist autor von" - "herr der ringe"

topicmaps macht was ähnliches nur auf eine höhere ebene, wäre also zB: dem schlagwortkatalog in der bilb. gleichzusetzen.

ISBN sollte nur als (Paradebeispiel) für eine unique-id herhalten, dem Grundprinzip des relationalen Datenbankmodells.

wollte ich jetzt echt pingelig sein müsste ich sagen, dass ISBN nich 100% eine UIND darstellt denn z.B. 3-8266-7209-7 verweist auf einige tausende bücher. aber ich bin nicht so pingelig *g*

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 ...

*lol* da haben wir es wieder: es geht dir ja doch noch nur um die performace. warum nur und ausschließlich darum? und warum habe ich das gefühl, dass ich gergeblich rede, wenn ich daruf hinweise, dass es mit der performace besser wird so wie die software hierzu immer besser wird.
oder war die erste oracle version genau so gut wie die 9i?

zum Auto: hast du einen wagen? mit klimaanlage? warum eigentlich?
ein Trabi aus 1970 würde ja auch tun: es fährt ja.

aber lassen wir diese hinkende vergleich.

Apropos Geld: Wie sieht es eigentlich mit Freeware/Open Source in Sachen XML-DBMS aus? MySQL kost' ja z.B. nix.

ich kenne noch keine freie xml-db, was nicht heisst dass es keine gibt und was nicht heisst dass es keine geben kann. wie du es selbst gesagt hast, diese technologie ist neu. also geben wir sie der zeit.

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!

ja, soweit kann und muss ich dem zustimmen.

Ich habe mir den von dir verlinkten Lesestoff 'mal zu Gemüte geführt.
Viel mehr als Werbung war das allerdings nicht.

du muss eben das wesentlich von unwesentlichen trennen.
obwohl es hier einge unterschiede gibt, kann man generell sagen, dass mit den xml-db kannnt du die dateien die im repository liegen indexieren (geht wohl auch mit einer altmodischen (*fg*) DB) was eben zu performacesteigerung führt bei der ausgabe der daten (übrigens beim textml-erver spricht man ebenfalls vom views, die man beliebig erstellen kann) nur du kannst diese indizes dann auch direkt verwenden: sie werden als XPath ausdrücke erstellt und somit direkt in einer xsl sheet verwendbar, ohne dass ich mit einer scripsprache das ganze belasten müsste (wie wohl es man kann)
es gibt dann db zu db noch viele andere möglichkeiten, aber das geht mir jetzt zu weit in meine arbeit und es ist wochenende.

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!?

ja, du liegst 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.

das ist fast immer das selbe.

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. ;-)

nein. xml dient nicht der verständigung (ich gehe jetzt nicht darauf ein, dass es natürlich möglich ist per RPC und XML auch anwendungen zu steuern, womit xml dann zu verständigungssprache wird)
xml ist die art der datenhaltung. xml ist d. format in dem die daten gespeichert werden.
und es soll DBs geben die xml genau auf die von dir beschriebene weise behandeln.

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?

prinzipiell richtig, aber nur dann wenn du für dich selbst 2 ansichten auf die daten benötigst, dann kast du mit verschiednene xsl-shets verschieden ansichten für deine daten erstellen.

wenn ud deine daten jemand anderen zusendest und der für sich dann in eine andere form umwandelt um damit zu weiterarbeiten, geht es (für mich) nicht mehr um daten (also nicht mehr um das gesamte xml mit tags etc) sondern um die austasuch von in diesen daten erhaltenen informationen. hier ist wie du früher vermerkt hast ist xml das austauschformat. genau das sit auch eine der vorteile von xml: ich kann sie überall verwenden. wie ist dass wenn jemand alles in eine oracle db hat und der andere alles in MySQL ... da gibt es dann nette probleme beim import-export. mit xml habe ich dieses probleme nicht.

was tabellen in einer DB angeht:
ist ja ekelhaft. :-)
Schlag mich tot: Ich find's toll! :-)
Sancta simplicitas!! :-þ

Na, herzlichen Dank auch! :-D

---zitat---
Schlag mich tot
-----------
du hast ja danach verlangt! ;-)

grüße und schönes wo.end
thomas

[kerki]

Hallo Thomas!

Es besitz ein jeder Message eine unique ID. [...] in den einzelnen threads-dienen dann die meeage nummer als ID [...] wenn du in einer DB falsch suchst bekommst du dort auch keine suchergebnisse. [...] http://forum.de.selfhtml.org/archiv/2002/1/2538/#m14419

Ich finde, wenn ich dem Computer sage "Gib mir die Message mit der Nummer 14419", habe ich meine Frage eindeutig formuliert. In welchem Thread sich diese Message befindet, sollte der Computer mir sagen, nicht ich ihm.

Klingt für mich wie: "Sagt der Büchereibesucher zum Bibliothekar: Nein, nein, sie müssen sich nicht die Mühe machen, mir zu erklären, wo ich das Buch finde. Zeigen sie mir einfach, wo es steht."

ich kann mir nicht vostellen, dass du ein einer DB anders machen würdest als durch einen "Pfad" zu suchen...oder muss in einer DB immer das gesamte datenbestand durchgesucht werden?

Jein! Ich kann jeden Datensatz einer Tabelle über dessen eindeutige ID direkt abfragen. In einfachen Datenbanken (z.B. CSV) kann das bedeuten, das ich die Tabelle von A bis Z durchlaufen muss, um an den gewünschten Datensatz zu gelangen.

In der Praxis eines DBMS wird dies aber durch entsprechende Indexierung mit ausgefeilten Sortieralgorythmen tunlichst vermieden.

[...] Im Prinzip sind "Links" aber doch auch nicht viel anderes als "Relationen" [...] das ist eben das plus an den links! willkürlich ist natürlich ein schöner ausdruck für "frei definierbare" ;-)

Finde ich auch! :-D

[...] oder http://forum.de.selfhtml.org/archiv/2002/1/2538.xml#xpointer(id('m14419')/Author/Name) würde fjh zurückliefern

SELECT author_name FROM messages WHERE message_id='m14419'

ebenfalls, ohne dass ich dem DBMS sagen müsste, in welchem Thread sich die Message überhaupt befindet.

SELECT message_topic, message_date FROM messages WHERE author_name='fjh' ORDER BY message_date

brächte mir eine chronologische Liste aller Messages mit Themen- mit Datumsangabe, die fjh je geschrieben hat.

Wie sähe denn so etwas analog in XML aus?

oder: http://forum.de.selfhtml.org/archiv/2002/3/5782.xml#xpointer string-range(//MessageContent,"Mumpitz")[1]

könne eines tages auf das erste vorkommen von "Mumpitz" in diesem thread hinlinken, ohne dass ich dafür 100-e von tabellen durchsuchen müsste!

Schön, aber woher nehme ich denn den Link? Woher weiß ich denn, in welchem Dokument sich das Wort 'Mumpitz' befindet? Ich kenne doch nicht das gesamte Archiv auswendig! Also muss ich doch wohl erst danach suchen, oder nicht?

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. das mit dem überblick geht mir genau so! ;-)

Das beruhigt mich jetzt ungemein. :-)

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.

ich sehe bloß keinen einzigen vernünftigen grund, warum ich das was zusammengehört erts in zig tabellen aufteilen muss/soll nur um später mühsamst wieder alles zusammenzufügen wenn ich es brauche.

Ich weiß nicht, wie ich es noch anders umschreiben soll, damit du verstehst, was ich sagen will: Die Daten gehören nicht zusammen. Beispielsweise Bücher thematisch zu strukturieren ist eine eine Möglichkeit. Eine alphabetische Struktur eine andere. Unter Umständen kann vielleicht sogar eine Sortierung nach Einbandfarben interessant sein (Für die Druckerei, die den Bedarf an Druckfarben fürs kommende Jahr plant).

Michael hat es, wie ich finde, in einem seiner Beiträge schön auf den Punkt gebracht:

"Ich denke, dieser Punkt zeigt vielleicht am besten, daß beide       Darstellungsformen unterschiedliche Ziele zu erreichen       versuchen:       XML konzentriert sich eben auf diese eine Strukturform, während       bei Relationen die Gleichwertigkeit beliebig vieler       Zusammengehörigkeiten oberstes Prinzip ist."

[...] register wären aber RDF oder TopicMaps also wiederum eine XML-"Anwendung" sehr einfach gesagt: RFD beschreibt recourcen in subjekt-prädikat-objekt form. simple katalogzettel in der bibliothek: "tolkien" - "ist autor von" - "herr der ringe"

Scheinbar bin ich wirklich zu blöd! :-(

Wenn ich eine buch.xml habe, in der (u.a.) steht:

<buch>   <titel>Herr der Ringe</titel>   <autor>Tolkien</autor> </buch>

habe ich doch alle nötigen Informationen beisammen. Brauche ich jetzt ernsthaft ein zweites Dokument, in dem steht, dass Tolkien der Autor von 'Herr der Ringe' ist?

ISBN sollte nur als (Paradebeispiel) für eine unique-id herhalten, dem Grundprinzip des relationalen Datenbankmodells. wollte ich jetzt echt pingelig sein müsste ich sagen, dass ISBN nich 100% eine UIND darstellt denn z.B. 3-8266-7209-7 verweist auf einige tausende bücher. aber ich bin nicht so pingelig g

Die Eigenschaften alle dieser Kopien eines Buches wird aber über die ISBN eindeutig beschrieben. Ein wiederholtes Abspeichern dieser Information ist somit hinfällig.

[...] Performance [...]

lol da haben wir es wieder: es geht dir ja doch noch nur um die performace. warum nur und ausschließlich darum? und warum habe ich das gefühl, dass ich vergeblich rede, wenn ich daruf hinweise, dass es mit der performace besser wird so wie die software hierzu immer besser wird.

Mit derselben Argumentation kannst du das Windows-BMP als ideales Bildformat für die Übertragung im Internet bezeichnen. Wenn die Übertragung halt ein wenig länger dauert, ist nicht etwa das Konzept schuld, sondern natürlich die Infrastruktur des Netzes oder der Anwender, der ein altes Modem benutzt.

zum Auto: hast du einen wagen? mit klimaanlage? warum eigentlich?

BTW: Mein Auto hat keine Klimaanlage. Wieso Autos in unseren Breiten neuerdings alle eine Klimaanlage brauchen, erschließt sich mir ohnehin nicht. Eine Standheizung wäre m.E. viel sinnvoller.

aber lassen wir diese hinkende vergleich.

Besser ist das! :-)

Apropos Geld: Wie sieht es eigentlich mit Freeware/Open Source in Sachen XML-DBMS aus? MySQL kost' ja z.B. nix.

ich kenne noch keine freie xml-db, was nicht heisst dass es keine gibt und was nicht heisst dass es keine geben kann. wie du es selbst gesagt hast, diese technologie ist neu. also geben wir sie der zeit.

Schade. Mit "Probieren geht über Studieren" ist also vorläufig Essig. :-(

obwohl es hier einge unterschiede gibt, kann man generell sagen, dass mit den xml-db kannnt du die dateien die im repository liegen indexieren (geht wohl auch mit einer altmodischen (fg) DB) was eben zu performacesteigerung führt bei der ausgabe der daten (übrigens beim textml-erver spricht man ebenfalls vom views, die man beliebig erstellen kann) nur du kannst diese indizes dann auch direkt verwenden: sie werden als XPath ausdrücke erstellt und somit direkt in einer xsl sheet verwendbar, [...]

Aha!

[...] ohne dass ich mit einer scripsprache das ganze belasten müsste (wie wohl es man kann)

Dieser Nebensatz ist für mich der Entscheidende.

XML, XSL und wie sie alle heißen sind doch auch Sprachen, die das ganze System belasten. Was macht sie denn nun besser als die bisher gebräuchlichen (Skript-)Sprachen?

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!? ja, du liegst richtig ;-)

Na, dann bin ich ja doch nicht so blöd wie ich aussehe! ;-)))

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.

das ist fast immer das selbe.

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. ;-)

nein. xml dient nicht der verständigung (ich gehe jetzt nicht darauf ein, dass es natürlich möglich ist per RPC und XML auch anwendungen zu steuern, womit xml dann zu verständigungssprache wird)

Schade, ich wollte aus XML eine mindestens 4GL machen. War wohl nix! :-(

xml ist die art der datenhaltung. xml ist d. format in dem die daten gespeichert werden.

und es soll DBs geben die xml genau auf die von dir beschriebene weise behandeln.

Hä? Wie kriegst du die beiden Sätze denn kompatibel?  =:-O Die beiden drücken doch gänzlich Gegenteiliges aus.

[... XML-Dokumente sind nur verschiedene Ansichten auf denselben (physikalischen) Datenbestand ...] Habe ich das Prinzip jetzt verstanden oder war das ein völliges Hirngespinst meinerseits?

prinzipiell richtig, aber nur dann wenn du für dich selbst 2 ansichten auf die daten benötigst, dann kast du mit verschiednene xsl-shets verschieden ansichten für deine daten erstellen.

Immerhin.

wenn ud deine daten jemand anderen zusendest und der für sich dann in eine andere form umwandelt um damit zu weiterarbeiten, geht es (für mich) nicht mehr um daten (also nicht mehr um das gesamte xml mit tags etc) sondern um die austasuch von in diesen daten erhaltenen informationen. hier ist wie du früher vermerkt hast ist xml das austauschformat.

Schade! Ich versteh's nicht. :-(

genau das sit auch eine der vorteile von xml: ich kann sie überall verwenden. wie ist dass wenn jemand alles in eine oracle db hat und der andere alles in MySQL ... da gibt es dann nette probleme beim import-export. mit xml habe ich dieses probleme nicht.

Mit SQL hast du das Problem prinzipiell auch nicht. Sicherlich stellt die unterschiedliche Implementierung des SQL-Sprach-"Standards" ein nicht geringes Problem dar. Einigt man sich auf den kleinsten gemeinsamen Nenner hat man auch kein Problem.

Ähnliche Probleme sind bei anderen Standards auch zu erwarten. (X)HTML  mag als Beispiel für XML reichen.

---

Ich glaube, so ganz ohne Beispiel aus der Praxis komme ich / kommen wir nicht weiter.

Wie würde eine klassische Datenbankanwendung wie etwa ein "Telefonbuch" in einem XML-Ansatz aussehen?

Mustermann, Hans     Musterstr. 17     12345 Musterhausen     Tel.: [phone]

Es ist mir ja wahnsinnig peinlich, aber weiter als bis

<eintrag>      <name>Mustermann, Hans</name>      <strasse>Musterstr. 17</strasse>      <plz>12345</plz>      <ort>Musterhausen</ort>      <vorwahl>01234</vorwahl>      <anschluss>12345</anschluss>     </eintrag>

komme ich nicht! :-[

Bei 2 Einträgen steh ich schon wie ein Ochs' vorm Berg! Mache ich jetzt 2 XML-Dateien? Eine eintrag1.xml und eine eintrag2.xml oder schreibe ich beide untereinander in ein XML-Dokument? Wie sähe es bei 1 Million Einträgen aus?

Wie kann ich in den Datenbeständen suchen? Wie füge ich Datensätze hinzu? Wie lösche ich?

Was hat das ganze überhaupt mit einem DBMS zu tun? Wie heißt denn jetzt das SQL-Pendant bei einem XML-DBMS? Wie bekomme ich denn jetzt "Leben in die Bude"?

Hier im Forum übernimmt das alles das Perl-Programm. Wie sähe es denn bei einem professionellen XDBMS-Server aus?

Ehrlich gesagt, bin ich im Moment "etwas" verwirrt.

Gruß,

ker* wie ein Häufchen Elend in sich zusammengesunken *ki

[Thomas J.S.]

hallo Kerki,

das wir jetzt mein letzter beitrag zum thema sein, da ich das gefühl nicht loswerde dass es hier nur noch um des diskussion willens weitergefragt wird. es tut mir sehr leid wenn ich mich irre und damit dir damit etwas unterstelle, was du gar nicht vorhast bzw. machst, nur mich fängt langsam an zu ärgern, dass ich -wohl gemerkt, nach meiner eigenen einschätzung! -  immer wieder das selbe erklären muss ohne das es wahrgenommen wird.

ich habe wenig gegen der einsatz von DBs, aber wohl gegen der einstellung, dass eine DB die lösung sein und xml eh nur unsinn von durchgeknallten typen ist. ich bin in meinem täglichen Arbeit immer wieder (d.h. fast ständig) mit xml konfrontiert und sehe welche gebiete mit xml aus der industie herausgehend besetzt werden. ich behaute nicht in allem einen sinn zu erkennen, aber für mich hat eben vieles dabei seine berechtigung.

Ich finde, wenn ich dem Computer sage "Gib mir die Message mit der Nummer 14419", habe ich meine Frage eindeutig formuliert. In welchem Thread sich diese Message befindet, sollte der Computer mir sagen, nicht ich ihm.

ja, richtig. und wo ist nun damit das problem? ich kann oracle anschrein bis ich grün bin, wird er mir nichts geben bis ich es mit den entsprechenden mittel ihm sage was ich will. warum sollte es bei xml plötzlich anders sein? hier brauche ich genau so das mittel zu mitteilung meiner wünsche, wichtig ist es gibt etwas was meine anfrage verarbeitet.

Jein! Ich kann jeden Datensatz einer Tabelle über dessen eindeutige ID direkt abfragen. In einfachen Datenbanken (z.B. CSV) kann das bedeuten, das ich die Tabelle von A bis Z durchlaufen muss, um an den gewünschten Datensatz zu gelangen.

In der Praxis eines DBMS wird dies aber durch entsprechende Indexierung mit ausgefeilten Sortieralgorythmen tunlichst vermieden.

1. ich muss die ganze tabellen anlegen und indexieren: absoluter overhead. beim xml brauche ich das nicht: eine xml datei enthält die schon gewünschte struktur und auch die informationen.
2. "ausgefeilten Sortieralgorythmen" die dann bei jeder DB ein klein wenig ander ausehen. in einer xml-bd kann ich genauso indexieren wobei die indexe dann gleichzeitig als "sortieralgorythmus" dienen kann. und dass standard für alle xml-db's weil in XPath, also in einer standard sprache.

SELECT message_topic, message_date FROM messages WHERE author_name='fjh' ORDER BY message_date

brächte mir eine chronologische Liste aller Messages mit Themen- mit Datumsangabe, die fjh je geschrieben hat.

Wie sähe denn so etwas analog in XML aus?

das kommt darauf an wie ich die xml daten/dateien verwarbeite, aber der entscheidener teil wäre mit xpointer: #xpointer string-range(//Author/Name ='fjh') oder eben <xsl:for-each select="//Author/Name='fjh'"> aber wie gesagt, es hängt davon ab wie ich die xml dateien behandele

oder: http://forum.de.selfhtml.org/archiv/2002/3/5782.xml#xpointer string-range(//MessageContent,"Mumpitz")[1]

könne eines tages auf das erste vorkommen von "Mumpitz" in diesem thread hinlinken, ohne dass ich dafür 100-e von tabellen durchsuchen müsste!

Schön, aber woher nehme ich denn den Link? Woher weiß ich denn, in welchem Dokument sich das Wort 'Mumpitz' befindet? Ich kenne doch nicht das gesamte Archiv auswendig! Also muss ich doch wohl erst danach suchen, oder nicht?

mir ging es nur um den einen thread. logischer weise kann ich das auch für viele dokumente machen, siehe weiter oben.

Ich weiß nicht, wie ich es noch anders umschreiben soll, damit du verstehst, was ich sagen will: Die Daten gehören nicht zusammen. Beispielsweise Bücher thematisch zu strukturieren ist eine eine Möglichkeit. Eine alphabetische Struktur eine andere. Unter Umständen kann vielleicht sogar eine Sortierung nach Einbandfarben interessant sein (Für die Druckerei, die den Bedarf an Druckfarben fürs kommende Jahr plant).

aber genau das ist was ich dir sagen will: die daten eines buches gehören zusammen: warum um himmels willen soll ich eine tabelle mit hunderten von autoren haben und eine mit hunderten von titel und eine mit hundere von ISBN nummer etc.

denn diese sortierungen sind unwichtig, diese kann ich mir aus der xml datei bei bedarf zusammenstellen: das sind nämlich die verschiedene sichten auf meine datenbetand. ich verwenden einfach einen filter und bekomme alle autoren, oder titel. aber ein buch gehört zu einem autor und zu einer ISBN nummer. das ist die wesentliche information: kompakt und vollständig. nicht aus der zusamenhang gerissen. ich kann sie jederzeit, ohne durch indexen von zig tabellen gehen zu müssen, bekommen (d.h. ich bin nicht genötigt erst den index buch zu finden, dann dort den index vom autor zu eruieren und dann erst in der tabelle der autoren nach dem autor zu suchen und dass selbe im grün mit der ISBN nummer, sonder ich erhalte diese infos sofort.)

alles ander ist bloße frage von sortierung und filterung der daten in der xml datei(en) für die ausgabe.

[...] register wären aber RDF oder TopicMaps also wiederum eine XML-"Anwendung" sehr einfach gesagt: RFD beschreibt recourcen in subjekt-prädikat-objekt form. simple katalogzettel in der bibliothek: "tolkien" - "ist autor von" - "herr der ringe"

Scheinbar bin ich wirklich zu blöd! :-(

Wenn ich eine buch.xml habe, in der (u.a.) steht:

<buch>   <titel>Herr der Ringe</titel>   <autor>Tolkien</autor> </buch>

knirsch du würdest in diesem fall nichts! über tolkien sagen sonder über: kerki - ist autor von - buch.xml ich habe mal für das archiv etwas gemacht: <?xml version="1.0"?> <rdf:RDF     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"     xmlns:dc="http://purl.org/metadata/dublin_core#"     xmlns:dcq="http://purl.org/metadata/dublin_core_qualifiers#">     <rdf:Description about="http://www.teamone.de/selfhtml/sfarchiv/">       dc:TitleSELFHTML Forums-Archiv</dc:Title>       dc:Date.Created2001-04-29T19:57+01:00</dc:Date.Created>       dc:Identifierhttp://www.teamone.de/selfhtml/sfarchiv/index.htm</dc:Identifier>       dc:DescriptionIm Forums-Archiv werden alte Nachrichten aus dem SELFHTML Forum       dauerhaft zitier- und verweisf&#228;hig gespeichert.</dc:Description>       dc:Creator</dc:Creator>       dc:Publisher</dc:Publisher>       <dc:Relation rdf:parseType="Resource">         <dcq:RelationType rdf:resource="http://purl.org/metadata/dublin_core_qualifiers#hasPart"/>          <rdf:li rdf:parseType="Resource">             dc:DescriptionQuartal 1998/3 (Juli bis September 1998)</dc:Description>             <rdf:value resource="http://www.teamone.de/selfhtml/sfarchiv/1998_3/index.htm"/>          </rdf:li>          <rdf:li rdf:parseType="Resource">             dc:DescriptionQuartal 1998/4 (Oktober bis Dezember 1998)</dc:Description>             <rdf:value resource="http://www.teamone.de/selfhtml/sfarchiv/1998_4/index.htm"/>          </rdf:li>          <rdf:li rdf:parseType="Resource">             dc:DescriptionQuartal 1999/1 (Januar bis M&#228;rz 1999)</dc:Description>             <rdf:value resource="http://www.teamone.de/selfhtml/sfarchiv/1999_1/index.htm"/>          </rdf:li>          <rdf:li rdf:parseType="Resource">             dc:DescriptionQuartal 1999/2 (April bis Juni 1999)</dc:Description>             <rdf:value resource="http://www.teamone.de/selfhtml/sfarchiv/1999_2/index.htm"/>          </rdf:li>          <rdf:li rdf:parseType="Resource">             dc:DescriptionQuartal 1999/3 (Juli bis September 1999)</dc:Description>             <rdf:value resource="http://www.teamone.de/selfhtml/sfarchiv/1999_3/index.htm"/>          </rdf:li>          <rdf:li rdf:parseType="Resource">             dc:DescriptionQuartal 1999/4 (Oktober bis Dezember 1999)</dc:Description>             <rdf:value resource="http://www.teamone.de/selfhtml/sfarchiv/1999_4/index.htm"/>          </rdf:li>          <rdf:li rdf:parseType="Resource">             dc:DescriptionQuartal 2000/1 (Januar bis M&#228;rz 2000)</dc:Description>             <rdf:value resource="http://www.teamone.de/selfhtml/sfarchiv/2000_1/index.htm"/>          </rdf:li>          <rdf:li rdf:parseType="Resource">             dc:DescriptionQuartal 2000/2 (April bis Juni 2000)</dc:Description>             <rdf:value resource="http://www.teamone.de/selfhtml/sfarchiv/2000_2/index.htm"/>          </rdf:li>          <rdf:li rdf:parseType="Resource">             dc:DescriptionQuartal 2000/3 (Juli bis September 2000)</dc:Description>             <rdf:value resource="http://www.teamone.de/selfhtml/sfarchiv/2000_3/index.htm"/>          </rdf:li>          <rdf:li rdf:parseType="Resource">             dc:DescriptionQuartal 2000/4 (Oktober bis Dezember 2000)</dc:Description>             <rdf:value resource="http://www.teamone.de/selfhtml/sfarchiv/2000_4/index.htm"/>          </rdf:li>       </dc:Relation>       dc:RightsCopyright @ 2000  [e-mail]</dc:Rights>

dc:Formattext/html</dc:Format>       dc:Languagede</dc:Language>

<dc:Relation rdf:parseType="Resource">         <dcq:RelationType rdf:resource="http://purl.org/metadata/dublin_core_qualifiers#IsPartOf"/>         <rdf:value resource="http://www.teamone.de/selfhtml/"/>       </dc:Relation>     </rdf:Description>   </rdf:RDF>

ISBN

Die Eigenschaften alle dieser Kopien eines Buches wird aber über die ISBN eindeutig beschrieben. Ein wiederholtes Abspeichern dieser Information ist somit hinfällig.

es wird nicht. es können in einem der kopien druckfehler drin sein, die das buch gegenüber den anderen auszeichen (bei münzsammlungen ist es oft so, dass dort zwar auch 1000 kopien einer münze gibt, die aber alle durchnummeriert sind. das ist eine uidn)

[...] Performance [...]

zu ganze nur noch soviel: du hast hier birnen mit apfel verglichen: daten übertragung in der leitung mit daten verarbeitung am server.

xsml-db:

Schade. Mit "Probieren geht über Studieren" ist also vorläufig Essig. :-(

du kannst dir sowohl tamino (90tage und verlängeerbar) als auch textml (30tage) frei testen.

Dieser Nebensatz ist für mich der Entscheidende.

XML, XSL und wie sie alle heißen sind doch auch Sprachen, die das ganze System belasten. Was macht sie denn nun besser als die bisher gebräuchlichen (Skript-)Sprachen?

xml und xsl sind eben keine scriptsprachen und du kannst sie überall verwenden. du brauchst nur noch ein xml/xsl prozessor (parser) egal welchen, wenn sie den standard verstehen. eine asp seite kannst du nicht in einer jsp umgebung laufen lassen und umgekehrt. wobei ich betonen muss dass weder xml noch xsl programmier- oder scriptsprachen sind! (auch wenn in xsl man schon einges anstellen kann was dem ziemlich nahekommt)

---

mist zu lang!!!

[Thomas J.S.]

fortsetzung:
-------

Schade, ich wollte aus XML eine mindestens 4GL machen. War wohl nix! :-(

4GL ??

Hä? Wie kriegst du die beiden Sätze denn kompatibel?  =:-O
Die beiden drücken doch gänzlich Gegenteiliges aus.

ich mnuss da gar nichts kompatibel krigen, dass müssen die, die die DBs so gestaltet haben.

wenn ud deine daten jemand anderen zusendest und der für sich dann in eine andere form umwandelt um damit zu weiterarbeiten, geht es (für mich) nicht mehr um daten (also nicht mehr um das gesamte xml mit tags etc) sondern um die austasuch von in diesen daten erhaltenen informationen. hier ist wie du früher vermerkt hast ist xml das austauschformat.

Schade! Ich versteh's nicht. :-(

was versteht du nicht?
tabellen in der DB sind fix und unflexibel.
die struktur in einer xml datei kann ich erweitern, bearbeiten etc. ohne dass die informationen an sich davon berührt werden würden.
ich kann aber wohl nicht so leicht die struktur in einer DB umschreiben.
sprich: du hast <Author>kerki</Author> ich habe <verfasser>kerki</verfasser> da ist "kerki" die information das andere rundherum ist die struktur, die ich nach belieben modifizieren kann.

Mit SQL hast du das Problem prinzipiell auch nicht. Sicherlich stellt die unterschiedliche Implementierung des SQL-Sprach-"Standards" ein nicht geringes Problem dar. Einigt man sich auf den kleinsten gemeinsamen Nenner hat man auch kein Problem.

sicher toll sich auf das minimum beschränken zu dürfen, aber wozu wenn ich das ganze haben kann?

---

Ich glaube, so ganz ohne Beispiel aus der Praxis komme ich / kommen wir nicht weiter.

Wie würde eine klassische Datenbankanwendung wie etwa ein "Telefonbuch" in einem XML-Ansatz aussehen?

Es ist mir ja wahnsinnig peinlich, aber weiter als bis

<eintrag>
     <name>Mustermann, Hans</name>
     <strasse>Musterstr. 17</strasse>
     <plz>12345</plz>
     <ort>Musterhausen</ort>
     <vorwahl>01234</vorwahl>
     <anschluss>12345</anschluss>
    </eintrag>

komme ich nicht! :-[

Bei 2 Einträgen steh ich schon wie ein Ochs' vorm Berg! Mache ich jetzt 2 XML-Dateien? Eine eintrag1.xml und eine eintrag2.xml oder schreibe ich beide untereinander in ein XML-Dokument? Wie sähe es bei 1 Million Einträgen aus?

z.B.:
<eintraege>
<eintrag> 1 </eintrag>
<eintrag> 2 </eintrag>
<eintrag> 3 </eintrag>
...
<eintrag> 1000000 </eintrag>
<eintraege>

es wurden schon experimente mit 2GB großen XML dateien gemacht.
aber du kannst natürlich mehrer dateien haben ein für jeden eintrag, oder pro buchstabe... hängt von dir ab.

Wie kann ich in den Datenbeständen suchen? Wie füge ich Datensätze hinzu? Wie lösche ich?

hängt vom anwendug ab, die du für die datenverarbeitung verwendest.

Was hat das ganze überhaupt mit einem DBMS zu tun?

keine ahnung. ich habe das nie behauptet.

Wie heißt denn jetzt das SQL-Pendant bei einem XML-DBMS?

XQuery, ist aber hier irrelevant.

»»Wie bekomme ich denn jetzt "Leben in die Bude"?

hängt vom anwendug ab, die du für die datenverarbeitung verwendest.

Hier im Forum übernimmt das alles das Perl-Programm. Wie sähe es denn bei einem professionellen XDBMS-Server aus?

wir würden mit xsl-sheets für die verschieden sichten des forums arbeiten (index, thread, message)
wir würden manche elemente in den xml dateien indexieren, damit das ganze etwas schnller läuft.
der rest hängt  weiderum von der xml-db ab (inkrementelles update der dateien,  etc.)

grüße
thomas

[Michael Schröpl]

Hi Thomas,

tabellen in der DB sind fix und unflexibel.
ich kann aber wohl nicht so leicht die struktur in einer DB umschreiben.

ich fürchte, die ganze Diskussion leidet sehr darunter, daß ihr beide von der jeweils anderen Materie zu wenig versteht.
Zu XML kann ich mangels eigener Kenntnisse nichts sagen, aber Deine Ansichten über relationale Datenbanken sind m. E. ziemlich am Thema vorbei, weshalb Du auch völlig unpassende Beispiele bringst. Natürlich wird beispielsweise niemand bei klarem Verstand versuchen, für einen Autor eine separate Tabelle zu definieren, _wenn_ zwischen Buch und Autor eine 1:1-Relation bestünde (bei einem Forum-Posting ist dies beispielsweise der Fall!) - in diesem Fall wäre das, was Du als "Delta-Quadrant" niederzumachen versuchst, einfach nur schlechtes relationales Design. Du kannst nicht das Modell kritisieren, indem Du es absichtlich fehlbedienst und dann das Ergebnis verspottest - das untergräbt die Seriosität Deiner Argumentation.

Da in der Realität allerdings eine 1:n-Besziehung zwischen Buch und Autor existiert, ist die entsprechende Zerlegung in der Tat notwendig, weil ein Feld einer relationalen Datenbank skalar, nicht aber mengenwertig ist. Daß dies bei XML-Strukturen offenbar anders ist, magst Du als Vorteil von XML ansehen; ich kann damit leben, in SQL zwei Tabellen zu verwenden, _weil_ ich dabei dann die entsprechenden Vorteile bei den Zugriffsverfahren genieße, und die lauten nicht zuletzt: Performance.

es wurden schon experimente mit 2GB großen XML dateien gemacht.

Mit welchen Performance-Ergebnissen?

Wie kann ich in den Datenbeständen suchen? Wie füge ich Datensätze hinzu? Wie lösche ich?
hängt vom anwendug ab, die du für die datenverarbeitung verwendest.

Mit welchen Performance-Auswirkungen?

Sorry, aber Performance _ist_ ein k.o.-Kriterium.

Ich möchte natürlich das Forum nicht mit einer Oracle-Datenbank vergleichen; aber wenn ich bestimmte Performance-Ansprüche an eine Installation habe, kann es gut sein, daß diese Ansprüche dann eben den Einsatz einer professionellen XML-Datenbank zwingend fordern würden, um diese Performance-Ansprüche zu erfüllen.
So gesehen wäre die Kritik an der aktuellen Implementierung des Forums keine Kritik an XML als solchem, sondern am Auswahlprozeß für die eingesetzte Software (nämlich Eigenbau statt Tamino & Konsorten).

Gibt es eine Freeware-XML-Datenbank, welche mit mySQL bezüglich Performance auch nur _halbwegs_ mithalten kann? (Laß sie um Faktor 5 schlechter sein, das wäre m. E. okay.) Wenn ja, warum wird sie vom Forum nicht verwendet? Wenn nein, ist es dann nicht einfach zu früh, XML als Datenspeicherungsform zu 'pushen'?

Viele Grüße
      Michael

[Michael Schröpl]

Hi Thomas,

1. ich muss die ganze tabellen anlegen und
   indexieren: absoluter overhead.

genau das ist der Punkt, der mir zeigt, daß Du das Wesen relationaler Datenbanken offenbar nicht verstanden hast.
Das Indexieren ist eben gerade _kein_ Overhead (sonst täte man es ja nicht), sondern eine Maßnahme zum Performance-Gewinn.

beim xml brauche ich das nicht: eine xml datei enthält die schon gewünschte struktur und auch die informationen.

Das ist das Mißverständnis von Deiner Seite: Es gibt nicht _die_ Struktur der Informationen.

Du kannst nicht die Problemstellung für XML auf etwas reduzieren, was SQL _ohne_ JOIN entspricht, und dann behauptet, XML wäre genauso gut wie SQL.

Es mag ja sein, daß es eine Klasse von Problemen gibt, welche mit sehr viel weniger auskommen würde als dem, was eine relationale Datenbank kann ... und wahrscheinlich gehört das Forum mit seiner extrem einfachen Datenstruktur sogar in diese Teilmenge der Probleme hinein.
Allerdings nur genau so lange, wie Du das Forum lediglich als Container für Threads ansiehst. Sobald weitere Strukturen hinzu kommen (Adressierung über beliebige andere Schlüsselsysteme als den einen per Default vorgesehenen), ist es vorbei mit der Idee, _die_ Struktur bereits in gespeicherter Form zu haben. Ganz abgesehen davon, daß Einfügen und Löschen in eine solche sortiert-gespeicherte XML-Struktur generell mindestens (!) genauso aufwändig sein _müssen_ wie das, was Du bei relationalen Datenbanken als 'Overhead' verdammt hast.

Viele Grüße
      Michael