nicht angemeldet
Große Tabelle - mehrere Tabellen Performance
Hallo Forum,
da anscheinend alle Nachrichten der letzten Tage verschwunden sind, schreib ich mal einen neuen Thread; hoffe das geht klar. Ich weiß nämlich nicht, ob schon jemand im Laufe des Tages geantwortet hat, weil ich verhindert war und deshalb seit gestern nicht im Forum nachschauen konnte.
Also jetzt zur Frage, und zwar ist eine Tabelle mit sehr vielen Einträgen schneller und besser zu Handhaben als mehrere Tabellen? Es geht um Gästebücher und zwar um sehr viele. Wenn sich etwa 14.000 Gästebücher in einer einzigen Tabelle befinden, ist dann die Abfrage langsamer, als wenn man die Datensätze jedes Gästebuch in mehrere Tabllen (also pro Gästebuch eine Tabelle) verteilt?
Ich vermute mal, dass, wenn man das ganze auf mehrere Tabellen verteilt, eine schnellere Abfrage gewährleisten kann; auch wenn man eine große Tabelle indizieren kann. Denn man müsste ja theoretisch die ganze Tabellen mit hunderten von tausend Beiträgen durchgehen, bis man diese Datensätze hat.
Was wären Vor- und Nachteile beider Techniken?
Ich bedanke mich für jede Antwort
Daniel
-
Moin!
Also jetzt zur Frage, und zwar ist eine Tabelle mit sehr vielen Einträgen schneller und besser zu Handhaben als mehrere Tabellen? Es geht um Gästebücher und zwar um sehr viele. Wenn sich etwa 14.000 Gästebücher in einer einzigen Tabelle befinden, ist dann die Abfrage langsamer, als wenn man die Datensätze jedes Gästebuch in mehrere Tabllen (also pro Gästebuch eine Tabelle) verteilt?
Gleichartige Daten sollten in _einer_ Tabelle gespeichert sein.
Wenn du die Tatsache, dass unterschiedliche Gästebücher mit dennoch gleichem Aufbau der Daten existieren, als hinreichend genug ansiehst, dafür mehrere Tabellen anzulegen, sei dir das unbenommen.
Die spannende Frage, was schneller ist, kann eigentlich nur ein Test beantworten.
Bedenke: Der Zugriffsaufwand über einen Index steigt logarithmisch mit der Zahl der Datensätze. Es macht kaum einen Unterschied, wenn bereits viele Datensätze vorhanden sind, noch ein paar Datensätze mehr hinzuzufügen. Dagegen ist es möglicherweise ein größerer Aufwand, erstmal den Index einer von 1000 Tabellen zu laden, um dann darüber auf eine sehr kleine Anzahl von Datensätzen zuzugreifen.
Im Sinne der Einheitlichkeit und des Vermeidens von unabsehbar vielen Tabellen würde ich dazu tendieren, nur eine einzige Tabelle zu eröffnen und darin alles zu speichern.
Ich vermute mal, dass, wenn man das ganze auf mehrere Tabellen verteilt, eine schnellere Abfrage gewährleisten kann; auch wenn man eine große Tabelle indizieren kann. Denn man müsste ja theoretisch die ganze Tabellen mit hunderten von tausend Beiträgen durchgehen, bis man diese Datensätze hat.
Du kennst die Funktionsweise eines Index nicht. Ein guter Index ist eine Baumstruktur. Als Beispiel nimm einfach mal einen binären Baum:
Es gibt einen Anfangsknoten. Darin steht der indizierte Wert, und es gibt zwei Zeiger auf weitere Knoten. Der linke Zeiger zeigt auf einen Teilbaum, in dem sich ausschließlich kleinere Werte als der im aktuellen Knoten gespeicherte befinden, der rechte Zeiger zeigt auf einen Teilbaum, in dem sich nur größere (oder auch gleich große) Werte befinden.
Statt also wie bei einer möglicherweise unsortierten linearen Liste jedes gespeicherte Element auslesen und vergleichen zu müssen, suchst du im Index sehr schnell: Du vergleichst den im Knoten gespeicherten Wert mit dem, der gesucht wird. Ist er gleich, hast du gefunden, was du suchtest - ansonsten gehst du entweder den linken oder den rechten Knoten entlang und wiederholst die Prozedur. Dieses Verfahren garantiert dir, dass nach einem Schritt bereits die Hälfte aller Datensätze wegfallen: Wenn du z.B. Zahlen kleiner als 50 suchst, und im Knoten ist eine 60 gespeichert, dann werden alle Datensätze mit Werten größer als 60, die sich im rechten Teilbaum befinden, nicht weiter beachtet. In der Regel ist man nach sehr wenigen Suchschritten am Ziel.
Kleines Beispiel:
Die gespeicherten Werte sind:
1, 4, 7, 12, 20, 34, 35, 36, 39, 43, 55, 56, 62, 78, 81, 87, 99Um in dieser linearen Liste den Wert 55 zu finden, mußt du mit allen vorhergehenden Werten vergleichen - insgesamt 11 mal, bis du den Wert gefunden hast. Und diese Liste ist sortiert! Das muß nicht zwingend so sein.
Mit einem wie oben beschriebenen binären Baum kannst du schöner arbeiten:
-------39---------
/ \ -----20---- ----62-----
/ \ / \ --7- -35- 55- -81-
/ \ / \ / \ / \ 1 12 34 36 43 56 78 87
\ \ 4 99Du fängst oben bei 39 an und vergleichst. Die gesuchte 55 ist größer, also folgst du dem rechten Zweig. Du findest die 62, welche größer als die 55 ist. Also links weiter. Und schon hast du gefunden, was du gesucht hast. 3 Vergleiche bis zum Ziel. Schlimmstenfalls hast du in diesem Baum 5 Vergleiche. Und wenn komplexere Baumstrukturen benutzt werden, dann hängen an einem Wert nicht nur zwei Werte, sondern mehr - die Tiefe des Baumes nimmt also ab, weil mehr Werte Platz haben - der Index wird effektiver.
Merke also: Indizes sind deine Freunde. Sie einzusetzen kann einen Datenbankzugriff extrem beschleunigen.
- Sven Rautenberg
--
"Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)-
Aloha,
also ich wusste zwar was ein Index ist und wofür man ihn gebraucht, aber wie das ganze funktioniert, wusste ich nicht.
Ein Bekannter, der viel mit Datenbanken zu tun hat, sagte mir heute morgen ähnliches... gleichartige Daten in einer Tabelle.
Er sagte mir auch, dass man bei einem Index aufpassen müsste, wenn man nur ein Index setzt und dann zwei gleichartige ID's vorhanden sind und der Schlüssel nicht mehr eindeutig ist, wird ein Datensatz gelöscht, bzw. ein Fehler wird ausgegeben. Müsste ich dann noch auf eine andere Spalte einen Index setzten?
Außerdem meinte er, dass es unter Umständen Probleme bei den Indexen bei etwa 500.000 Datensätzen kommen kann (zumindest bei Paradox).
Macht MySQL damit Probleme?Danke dir - hat mir wirklich schon sehr geholfen!
Daniel
-