nicht angemeldet
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