nicht angemeldet
yo,
zuerst mal: es heisst der Index und die Indizes ;-)
na meine schreibfehler machen mich doch menschlich. ;-)
für den es widerum auch einen cache gibt und somit ausführungpläne
ebenfalls schon vorliegen oder ich ihm genau sagen kann, wie man
vorgeht.Öhm -- und?
was die ausführung beschleunigt, solch einen cache gibt es bei den dateien nicht, sprich wenn ich kein dbms benutze. hier muss ich jedesmal aufs neue herausfinden, wie ich am besten vorgehe, selbst wenn es die gleiche anweisung ist, es sei den, ich gehe immer gleich vor, was aber zwangsläufig auch performance kosten würde. und das die beste geschwindigkeit keinen festen algorithmus besitzt, dass muss ich ja nicht erst erwähnen oder ? es nützt mir also wenig, wenn ich auf eine datenstruktur immer algorithmus A anwende, weil je nach datenbestand sich das ändern kann. und diese müsste dein programm ebenfalls erst noch "herausarbeiten" und wenn sie das effektiv machen wollen, also auch mit cache, etc, dann werden sie immer mehr zu, na zu dbms.
Herjemine. Sortierte Daten halt. Warum sollte es langsamer sein?
hast du eine ahnung, was das an zeit kostest, unsortierte daten zu sortieren ? alle reinladen und sortieren ist zig mal langsamer als einen index zu benutzen, ausser besimmte fälle wie wenige daten, etc.
und ich habe dir schon mal erklärt, dass du nur eine sorierung physisch abbilden kannst, es aber die praxis ist, dass datenstrukturen mehrere sortierungen brauchen.
Im Falle eines Stromausfalls meinst du.
yo genau, stromausfall oder defekte graphikkarte. da waren zuviele platten im spiel. ;-) hast du keine batteriepufferung der festplatten, was nun mal nicht jede hat, dann heisst das ganz einfach bei datenbanken, bitte den cache ausschalten. ansonsten kann es zu bösen fehlern kommen. ausserdem laufen über den platten cache noch andere daten. die gar nichst mi den daten der datenbank zu tun haben.
Hae? Natürlich ist die Entscheidung, ob ich einen Idex benutze
und welche, unabhängig von meiner Umgebung. Das habe ich doch
gar nicht bestritten?
dann hast du dich schlecht ausgedrückt oder ich dich schlecht verstanden. dann sind wir uns ja einig, dass man sortierungen braucht, egal welchen weg man nun geht, um daten zu speichern und können diesen punkt abhacken.
und dann muss auch jedesmal der gesamte datenbestand sortiert
werden, wenn neue einträge hinzukommen oder alte gelöscht werden.Quatsch. Das hiesse ja, eine Datenbank müsste jedesmal den Index
komplett neu erstellen. Wie komst du auf so einen Unfug?
erstens ist es ein unterschied, ob ich einen index neu sortiere oder den kompletten datenbestand. und wir reden ja von effizienz. zweitens hat eine dbms dafür bestimmte mechanism, damit eben nicht jedesmal der index neu erstellt werden muss und er sogar online neu erstellt werden kann und zwar unter zuhilfenahme des alten. dass müsstest du im prinzip in deinen dateien auch mit einbauen. und somit kommst du immer wieder auf das gleiche ergebnis. willst du daten effektiv verwalten, benutzt du instrumente, wie sie auch bei dbms benutzt werden.
Ich sagte 'im Normalfall'. Ich sagte nicht 'ausschliesslich'. Das
Datenbanken auch andere Index-Typen kennen weiss ich selber. Und
ich hoffe dir ist auch bewusst, das es nur an mir liegt, wie ich
meine Daten organisiere.
was soll dann der vergleich mit der binären suche, dass können dbms auch. ist doch klar, wenn ich die mechanism des dbms falsch einsetzte und einen b-baum nutze, wo ein bitmap her muss, dass sich das negativ auswirkt.
Lies am besten mal ein gutes Buch über Algorithmen und
Datenstrukturen.
welche auch in den datenbanken implementiert sind. als ob man diese nicht bei dbms nutzen könnte. ist doch kein vorteil der blossen datei-haltung.
[ ] Du hast mich verstanden.
Datenbanken sind nur die Verallgemeinerung und Standardtisierung von
spezialisierten Datei-Algorithmen. Eine spezialisierte Lösung *muss*
immer schneller sein, weil sie viel, viel weniger beachten muss.
[ ] leider hast du meine aussagen nicht verstanden und die besagt, ohne die mechanism von dbms sind bestimmte otpiermierungen bezüglich der schnellingkeit nicht zu nutzen und das wird die datenverwaltung erheblich langsamer machen. datenbanken sind mehr als einfach nur eine verallgemeinerung. sie bieten, und jetzt kommt der entscheidene satz, ZUSÄTZLICHE möglichkeiten der optimerung an.
insofern stimmt deine aussage nicht. der clou der dbms ist, dass man nicht mehr direkt auf die daten zugreift. ich kann den logischen schritt nachvollziehen, dass du nun sagtst, dass kostet mich erst einmal performance. ABER durch diesen umweg gewinnt man eine ganze menge andere vorteile und unter dem strich ist das wesentlich effektiver.
Hab ich geschrieben, dass ich geänderte Daten nicht schreibe? Nein,
habe ich nicht. Hast du geschrieben, dass du geänderte Daten nicht
schreibst? Nein, hast du nicht. Was also hat das ganze mit dem Zitat
oben drüber zu tun?
doch genau das war meine aussage. dbms müssen änderungen nicht sofort auf platte schreiben, du musst das tun.
Stell dir vor, es gibt auch DBMS, die *nicht* mit SQL und/oder als
Server-System arbeiten.
und nun ?
Nein, wir haben eine _spezialisierte_ Form eines DBMS.
nein hast du nicht, solange du direkt auf daten zugreifst. versuche das zu verstehen, dass dies ein nachteil ist, der sich auch auf die performance auswirkt und zwar negativ.
Quatsch. Ich habe dir schon einmal erklärt, dass auch Datenbanken nur
mit Wasser kochen.
was ist verkehrt mit wasser zu kochen, ich mache das auch ? die frage ist ja nicht, kein wasser zu nehmen, sondern mit welcher methode bekommen wir es scheller zum kochen.
Ilja