nicht angemeldet
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.
- 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.
- "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ä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ä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ä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 selfhtml@teamone.de</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!!!