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