Hallo,
Nur, dass ein RDBMS diese Funktionalität bereits integriert hat und sie hier extra ist.
ist mit "extra" gemeint, dass es dafür fertige "ich simuliere mit xml-files eine datebank"-schnittstellen gibt, oder ist das alles eine eingene lösung?
Du denkst viel zu relational. ;-)
Stell Dir nun einmal vor, Du hast 1000 Adressdatensätze. Wenn Du die auf der Festplatte abspeicherst, dann müssen die ja irgendwie hintereinander gespeichert werden (in welchem exakten Format auch immer) - egal ob nun von einer Datenbank oder nicht. Die Idee ist nun: Wenn Sie hintereinander gespeichert werden, dann müsste man, um zum Beispiel nach einem bestimmten Nachnamen zu suchen, alle Datensätze hintereinander durchgehen - und das dauert halt seine Zeit, bis man 1000 Datensätze durchsucht hat.
Wenn man jetzt aber zum Beispiel *zusätzlich* zu den eigentlichen Daten noch einen Index - im einfachsten Fall zum Beispiel einen binären Baum (in der Realität werden meist etwas kompliziertere Datenstrukturen genutzt), dann könnte man sich z.B. sowas aufbauen (jetzt mal nur ein Ausschnitt):
+--------------+
| McKinley: 25 |
+--------------+
/ \
/ \
+-------------+ +----------+
| Kennedy: 35 | | Taft: 27 |
+-------------+ +----------+
/ \ / \
/ \ / \
+----------+ +------------+ +-----------+ +---------------+
| Adams: 2 | | Licoln: 16 | | Nixon: 37 | | Washington: 1 |
+----------+ +------------+ +-----------+ +---------------+
Im binären Baum würden dann die Informationen "Nachname" und "Position in den realen Daten" gespeichert werden (das ist hier die Nummer). Wenn man dann nach einem Nachnamen sucht, dann macht man z.B. folgendes:
Suche Adresse von "Nixon":
* Vergleiche mit oberstem Knoten im Index (McKinley)
-> Kommt später im Alphabet
-> Ein Knoten nach Rechts
* Vergleiche mit aktuellem Knoten (Taft)
-> Kommt früher im Alphabet
-> Ein Knoten nach Links
* Vergleiche mit aktuellem Knoten (Nixon)
-> Gefunden!
* Suche Datensatz nummer 37 aus den eigentlichen Daten heraus
Beachte, dass die Zahl nicht unbedingt eine fortlaufende Datensatznummer sein muss (wie hier in diesem einfachen Beispiel), sondern durchaus z.B. ein Offset in einer großen Datei sein kann (soundsoviel Bytes ab Begin der Datei), wo halt der Datensatz anfängt.
So funktionieren Indizes im Allgemeinen. Wenn man es mit Laufzeitkomplexitätsklassen ausdrücken will, brauchen Indizes bei n Datensätzen nur log(n) Vergleiche, um zum Ziel zu kommen (bei 1000 wären das z.B. 10, bei 1000000 wären es 20, bei 1000000000 wären es 30, etc.), während man ohne Index n Vergleiche durchführen muss (bei 1000 wären es also weiterhin 1000, bei 1000000 wären es 1000000, etc.).
Wenn Du eine relationale Datenbank hast, dann liefert die einen Indexmechanismus gleich mit, d.h. wenn Du sowas machst wie
CREATE INDEX name_des_indizes ON tabelle (spalte);
dann führt ein
SELECT * FROM tabelle WHERE spalte = 42;
automatisch zur Verwendung des Indizes, d.h. Du musst Dich um nichts mehr kümmern.
Wie ich oben allerdings dargelegt habe, sind Datenbanken mit Sicherheit nicht diejenigen, die Indizes erfunden haben. Sie nutzen sie nur. Man kann so einen Index (man muss ihn halt geeignet abspeichern) auch relativ problemlos selbst verwenden. Es wäre absoluter Blödsinn, für sowas eine Emulationsschicht für ein RDBMS zu verwenden, das im Hintergrund die XML-Dateien verwendet, wenn wir sowieso schon alles als XML zur Verfügung haben. Deswegen auch die ausführliche Antwort auf Deine Frage, Du scheinst nämlich nicht verstanden gehabt zu haben, dass relationale Datenbanken in der Datenhaltung nicht ein Monopol haben. Sie spielen eine wichtige Rolle, es gibt aber sehr viele Awnendungen (zum Beispiel Dein Dateisystem - ist ja auch ein Datenhaltungssystem ;-)), die keine *relationale* Datenbank im Hintergrund verwenden, die jedoch oftmals auf ähnliche Konzepte zurückgreifen.
So, und nachdem ich das alles erzählt habe, wie sowas im Idealfall funktioniert, darf ich Dir die Illusionen gleich mal wieder kaputt machen: Wir bei SELFHTML verwenden aktuell noch eine Suche, die in Perl geschrieben wurde, die nichts anderes macht, als eine *reisige* Textdatei (unser "Index", aber halt kein Baum wie oben, sondern ein linearer Index) zeilenweise einzulesen und jede Zeile mit dem Suchbegriffen zu vergleichen (jede Zeile ist ein Posting, dessen Text um bestimmte Sonderzeichen wie Neue-Zeile-Zeichen bereinigt wurde) und dann die entsprechenden Postings auszuspucken. Das ist natürlich bei der Menge an Postings sehr ineffiizent und deswegen verstehst Du jetzt hoffentlich auch, warum die Suche bei uns gerne mal 10 Sekunden braucht, *obwohl* wir sauschnelle und nichtausgelastete Hardware hier haben. Dass die Suche trotz des Designs immer noch so schnell ist, zeigt eigentlich, dass die Hardware sehr gut ist. ;-)
Allerdings kann ich Dich beruhigen: Wir hatten vor einiger Zeit uns darum bemüht, jemanden zu finden, der die Suche bei uns neu entwickelt. Es hat sich dankenswerterweise jemand gefunden (Jens Krämer), der inzwischen eine neue Suchfunktion auf Basis von Ferret/Stellr (Ruby) entwickelt hat. Ferret ist das Ruby-Äquivalent von Lucene, was ein Framework für Volltextsuchanwendungen darstellt und darauf abgestimmte Indexstrukturen bietet. Da wollten wir im Prinzip schon vor Ewigkeiten einen öffentlichen Betatest machen, dass das bisher noch nicht stattgefunden hat, liegt an mir, wie ich zugeben muss.
Viele Grüße,
Christian