Effizienz-Vergleich MySQL-Eintrag vs. Datei-Eintrag

[Felix]

Hallo Leute,

in meinem Projekt wird bei jedem Laden von jeder Seite ein Datensatz mit gewissen Informationen erzeugt. Diese Informationen sind pro Datensatz im Durchschnitt etwa 20 Bytes lang.

Welche Methode ist nun schneller und damit effizienter und kundenfreundlicher:

Log-Datei öffnen
Datensatz eintragen
Log-Datei schliessen

oder:

MySQL Connect herstellen
Datensatz eintragen

Besonderheiten:
Bei den meisten Seiten wird sowieso schon die Verbindung zur DB vor dem Loggen hergestellt.

Man muß auch die Dateigröße der Log-Datei bzw. Datenbank berücksichtigen. Da kommt sehr schnell eine gewisse Datenmenge zusammen.

Hat jemand zu diesem Thema schon mal ausführliche Untersuchungen angestellt?

Gruß,
Felix

[Christian Kruse]

Hallo Felix,

[... Performance-Vergleich Datenbank, Datei-Aktionen ...]

Eine Interaktion mit der DB muss immer langsamer sein als ein simples
schreiben in eine Datei. Dabei spielt die Größe der Datei beim
Eintragen keine Rolle: die Größe ist bekannt und ein Anhängen kostet
nicht viel. Bei einer Auswertung hinterher könnte es evntl. von
Nachteil sein, je nach dem was du vor hast.

Grüße,
 CK

[Ilja]

yo,

grundsätzlich würde ich sagen, sind datenbanken effektiver, da sie genau dazu ausgerichtet sind und auch eine reihe von mitteln zur verfügung stellen, die es so bei einer dateispeicherung nicht gibt, zum beispiel die möglichkeit der indizierung oder logische einheiten von informationen zu bilden, sie aufzuteilen und wieder zu verbinden.

letztlich muss man das aber für jeden einzellfall sehen. es kommt darauf an, wie die daten gespeichert werden und vor allem wie darauf zugegriffen wird. widerholen sich informationen, die in der datei gespeichert wird und willst du einfach nur alle daten der reihe nach ausgeben oder willst du auch nach bestimmten daten suchen. sobald sich daten wiederholen oder man gezielt sucht, wird eine datenbank eine dateispeicherung um längen schlagen, wenn wir mal nicht gerade von zwei datensätzen ausgehen.

Ilja

[Christian Kruse]

Hallo Ilja,

sobald sich daten wiederholen oder man gezielt sucht, wird eine
datenbank eine dateispeicherung um längen schlagen, wenn wir
mal nicht gerade von zwei datensätzen ausgehen.

Das viel zu absolut und nicht wahr. Bedenke, dass Datenbanken eine
Verallgemeinerung eines Problems sind. Verallgemeinerungen
sind idR nicht so schnell wie spezialisierte Lösungen. Kann eine Datei-Suche z. B. binär durchgeführt werden, so kann sie problemlos
um ein vielfaches schneller sein als eine Datenbank-Lösung. Datei
ist nicht gleich linear. Der Grund, warum Datenbanken verwandt
werden, ist der, dass solche Algorithmen a) kompliziert zu
implementieren sind und b) relativ vielen Einschränkungen
unterliegen (z. B. fixe Datenlänge).

Grüße,
 CK

[Ilja]

yo,

Der Grund, warum Datenbanken verwandt
werden, ist der, dass solche Algorithmen a) kompliziert zu
implementieren sind und b) relativ vielen Einschränkungen
unterliegen (z. B. fixe Datenlänge).

nein, dass sehe ich ganz anders. datenbank haben primär den grund, um datenunabhängigkeit zu schaffen. dies sieht auf den ersten blick so aus, als wenn das mit performance erkauft werden müsste. und ich gebe dir recht, wenn datensätze einfach nur hintereinander in dateien geschrieben werden und immer wieder alle zusammen ausgelesen werden, dann ist der umweg über eine datenbank langsamer.

ABER, will man das, immer alle daten lesen und immer alle daten eines Datensatzes reinschreiben ? wenn man das nämlich nicht will, dann wird die datenbank schneller sein, es sein denn, man macht genau das gleiche, was auch eine datenbank macht, zum beispiel indizes anlegen. such mal aus 1 millionen datensätze einen bestimmten eintrag ohne einen solchen indize zu besitzen. eine blosse dateispeicherung wird das nämlich nicht tun. und dann wirst du sehen, dass eine datenbank um ein vielfaches schneller ist. und auch beim schreiben muss eine datenbank nicht immer gleich alle daten schreiben, sondern eben nur die wirklich neuen, dadurch dass es in der lage ist, informationen aufzuteilen und logisch miteinander zu verknüpfen.

Ilja

[Andreas-Lindig]

Hallo Ilja,

und auch beim schreiben muss eine datenbank nicht immer gleich alle daten schreiben, sondern eben nur die wirklich neuen, dadurch dass es in der lage ist, informationen aufzuteilen und logisch miteinander zu verknüpfen.

jetzt mal noch ne Frage zu Christians erstem Posting: Nur die neuen Daten hinten dran schreiben. Also die Datei wird geöffnet, Dateizeiger steht am Ende und der neue Eintrag wird hinten angehängt (ist mir auch noch nie mittendrin gelungen). Wird dann das lesen der ganzen Datei gespart oder nicht? Die Datei wird also ausdrücklich nicht mit fread() oder wasauchimmer eingelesen.

Gruß, Andreas

[Christian Kruse]

Hallo Andreas,

jetzt mal noch ne Frage zu Christians erstem Posting: Nur die neuen
Daten hinten dran schreiben. Also die Datei wird geöffnet,
Dateizeiger steht am Ende und der neue Eintrag wird hinten
angehängt

Korrekt.

(ist mir auch noch nie mittendrin gelungen).

Man fseek() ;-)

Wird dann das lesen der ganzen Datei gespart oder nicht?

Die Datei wird *nicht* gelesen. Das wäre ja Wahnsinn. Nein, es wird
einfach nur an das Ende der Datei gesprungen.

Grüße,
 CK

[Andreas-Lindig]

Hallo ,

Hallo Andreas,

auch so... äh, Hallo Christian

(ist mir auch noch nie mittendrin gelungen).
Man fseek() ;-)

ja-haaaa! Habe ich probiert, habe mir auch jeweils die Stellung des Dateizeigers ausgeben lassen und er stand tatsächlich immer da, wo er sein sollte, nur das darauffolgende _Schreiben_ ging immer automatisch ans Ende der Datei. Seitdem lese ich immer eine Datei komplett aus, füge die Änderungen da ein, wo es soll und überschreibe die Datei komplett.

Gruß, Andreas

[Christian Kruse]

Hallo Andreas,

Hallo Andreas,
auch so... äh, Hallo Christian

?

(ist mir auch noch nie mittendrin gelungen).
Man fseek() ;-)

ja-haaaa! Habe ich probiert, habe mir auch jeweils die Stellung
des Dateizeigers ausgeben lassen und er stand tatsächlich immer
da, wo er sein sollte, nur das darauffolgende _Schreiben_ ging
immer automatisch ans Ende der Datei.

Wie hast du die Datei denn geöffnet? Geht bei mir problemlos:

ckruse@rain:~/www/default/htdocs $ cat test.txt
abcdef
ckruse@rain:~/www/default/htdocs $ cat test.php
<?php

$fd = fopen('test.txt','r+');
fseek($fd,2,SEEK_SET);
fwrite($fd,'a');
fclose($fd);

?>
ckruse@rain:~/www/default/htdocs $ php test.php
ckruse@rain:~/www/default/htdocs $ cat test.txt
abadef
ckruse@rain:~/www/default/htdocs $

Grüße,
 CK

[Andreas-Lindig]

Hallo Christian,

jetzt hatte ich so viel zu tun, daß ich erst jetzt geschafft habe, Dein Script zu probieren.

...nur das darauffolgende _Schreiben_ ging

immer automatisch ans Ende der Datei.

Wie hast du die Datei denn geöffnet? Geht bei mir problemlos:
[...]

geht bei mir auch problemlos ;) Ich habe sie wohl früher mit fopen('datei.txt','a'); geöffnet, dann geht's laut Doku auch nur am Ende. Nun weiß ich: lesen hilft ;)

Gruß, Andreas

[Tom]

Hello,

jetzt mal noch ne Frage zu Christians erstem Posting: Nur die neuen Daten hinten dran schreiben. Also die Datei wird geöffnet, Dateizeiger steht am Ende und der neue Eintrag wird hinten angehängt (ist mir auch noch nie mittendrin gelungen). Wird dann das lesen der ganzen Datei gespart oder nicht? Die Datei wird also ausdrücklich nicht mit fread() oder wasauchimmer eingelesen.

Na, nicht so ganz.

Schreib- und Leseköpfe lassen sich auf Festplatten nur so ungefähr positionieren, also nicht genau auf einem Bit. Der Kopf benötigt eine Landezone, den sogenannten Rasenstreifen. Dort setzt er auf und fängt an zu lesen, immer blockweise. Auch beim Schreiben können nur komplette Blöcke geschrieben werden, auch wenn nur ein Byte verändert wurde. Das ist für die Datenmenge natürlich nachteilig, aber von Vorteil für den Refresh der Festplatte, die sonst irgendwann auch ihre Daten vergessen würde.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Christian Kruse]

Hallo Tom,

Schreib- und Leseköpfe lassen sich auf Festplatten nur so ungefähr
positionieren, also nicht genau auf einem Bit.

Stimmt nicht ganz. Die Köpfe können recht genau positioniert werden,
nur die Adressierung ist nicht möglich, da man sich (im Falle eines
PCs) auf 32 Bit beschränken muss.

Der Kopf benötigt eine Landezone, den sogenannten Rasenstreifen.
Dort setzt er auf

Gott bewahre! Wenn das so wäre, hättest du mehr Datenfehler als du
zählen könntest. Tatsächlich bleibt immer ein Luftpolster zwischen
Magnetscheibe und Kopf. Headcrash ist nämlich genau das: das
Luftpolster geht kaputt und der Kopf pitcht einmal kurz auf die
Scheibe und es kommt zu defekten Sektoren auf der HD.

[...] aber von Vorteil für den Refresh der Festplatte, die
sonst irgendwann auch ihre Daten vergessen würde.

HD != RAM.

Grüße,
 CK

[Tom]

Hello,

Gott bewahre! Wenn das so wäre, hättest du mehr Datenfehler als du
zählen könntest. Tatsächlich bleibt immer ein Luftpolster zwischen
Magnetscheibe und Kopf. Headcrash ist nämlich genau das: das
Luftpolster geht kaputt und der Kopf pitcht einmal kurz auf die
Scheibe und es kommt zu defekten Sektoren auf der HD.

"Aufsetzen" musst Du Dir natürlich nicht wörtlich übersetzen. Dass der Kopf über einem Luftpolster schwebt, ist mir auch klar. Beim Spurwechsel benötigt er allerdings wieder einen Moment, um zu "synchronisieren". Dazu gibt es zwischen den Clustern diese "Rasenstreifen", in denen die Sync-Daten liegen. Dadurch kann die Elektronik der Platte jederzeit sagen, in welchem Cluster sich der Kopf befindet.

Es werden immer vollständige Cluster ausgelesen und wieder weggeschrieben. Es ist der Platte nicht möglich, einzelne Bit neu zu setzen.

Nach außen merkt man das natürlich heute nicht mehr, das das System als (E)IDE-System das alleine regelt. Und bei SCSI sowieso.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Christian Kruse]

Hallo Ilja,

Der Grund, warum Datenbanken verwandt
werden, ist der, dass solche Algorithmen a) kompliziert zu
implementieren sind und b) relativ vielen Einschränkungen
unterliegen (z. B. fixe Datenlänge).

nein, dass sehe ich ganz anders. datenbank haben primär den grund,
um datenunabhängigkeit zu schaffen.

Das geht recht problemlos auch mit Dateien.

ABER, will man das, immer alle daten lesen und immer alle daten
eines Datensatzes reinschreiben ?

Du hast mich nicht verstanden. Das ist doch gar nicht nötig. Bei
einer fixen Datensatzlänge weiss ich genau, wo ich schreiben oder
lesen muss. Da muss ich immer höchstens *einen* Datensatz lesen,
bei einer Suche etwas mehr (abhängig vom Sortier-Verfahren). Und ich
muss auch nur höchstens *einen* Datensatz schreiben, uU sogar nur
einen *Teil* des Datensatzes. Was meinst du, wie eine Datenbank das
macht? Die macht das genau so, nur verallgemeinert.

wenn man das nämlich nicht will, dann wird die datenbank schneller
sein, es sein denn, man macht genau das gleiche, was auch eine
datenbank macht, zum beispiel indizes anlegen.

Indizes sind ein Hinweis für die Datenbank, dass es sich hier lohnen
kann, auf eine andere Art als linear zu suchen. Das heisst, bei einer
eigenen Umgebung brauche ich keine Indizes. Da kann ich selber
entscheiden, wie ich suche. Ob binär, ob per Hash-Index, das bleibt
völlig mir überlassen.

such mal aus 1 millionen datensätze einen bestimmten eintrag ohne
einen solchen indize zu besitzen. eine blosse dateispeicherung wird
das nämlich nicht tun.

Das brauche ich auch nicht.

und dann wirst du sehen, dass eine datenbank um ein vielfaches
schneller ist.

Nein. Bei einer binären Suche z. B. wird der Aufwand logarithmisch,
da sind maximal ln 1000000 / ln 2 = 20 Vergleiche notwendig.

und auch beim schreiben muss eine datenbank nicht immer gleich alle
daten schreiben, sondern eben nur die wirklich neuen,

Dito bei Dateien.

Wirklich, der einzige Grund, warum man Datenbanken benutzen sollte
ist der, dass wenige Leute das auch noch wirklich so hinkriegen und
es eine Heidenarbeit ist.

Grüße,
 CK

[Ilja]

yo,

ohne jetzt hier eine grundsatzdiskussion loszulassen, lass uns mal punkt für punkt durchgehen. als erstes den sinn einer datenbank, warum man so etwas überhaupt macht. datenbanken sind wie alles gewachsen, sprich aus problemen enstanden. früher ist man genau den weg gegangen, den du hier beschreibst, jedes programm hatte seine daten in dateien geschrieben.

Das geht recht problemlos auch mit Dateien.

und genau das geht eben nicht, aus diesem grund gibt es datenbanken. stell dir mal vor, du hast deine datendateien und ein programmierer findet nun eine besser möglichkeit daten zu speichern und wieder abzurufen. dann muss nicht nur er sein programm ändern, sondern alle anderen programe müssen dies auch tun. und auch die strukturen der daten müssen übereinstimmen. aber nicht jedes programm will die gleichen strukturen haben. ergo gab es ein problem, man war an den daten gebunden. jede abeiteilung hatte unterschiedliche daten strukturen und somit waren die gleichen daten mehrfach vorhanden, eben nur in anderen sturkturen.

und um dises problem zu lösen, hat man datenbanken entwickelt. diese datenbanken haben sich nun darum gekümmert, wie die daten verwaltet werden und programme haben nicht mehr direkt auf die daten zugegriffen. damit erreichte man eine datenunabhängigkeit, die für unternehmen sehr, sehr wichtig ist. ok, damit ist schon mal der sinn klar, warum es datenbanken gibt. aber sind diese nun schneller oder langsamer als der weg über dateien ? dazu nehmen wir mal dein beispiel, wo ich dich nicht verstanden habe.

Du hast mich nicht verstanden. Das ist doch gar nicht nötig. Bei
einer fixen Datensatzlänge weiss ich genau, wo ich schreiben oder
lesen muss. Da muss ich immer höchstens *einen* Datensatz lesen,
bei einer Suche etwas mehr (abhängig vom Sortier-Verfahren).

yo, und genau hier setze ich an und zwar ganz genau bei den worten "etwas mehr". wenn du weisst, wie ein b-Baum oder bitmap indize funktioniert, dann würde dir das "etwas mehr" viel konkreter werden. dazu habe ich versucht, dir das mal für eine million datensätzen zu überlegen. ohne indize ist dafür ein sogenannter fullscan notwendig, sprich eine million mal muss er einen datensatz anfassen und entscheiden, ob er in das gute töpfschen kommt oder nicht. und dabei ist dr algorythmus so ziemlich egal, den du dabei anwendest, den die daten liegen nicht sortiert vor. und nun überleg mal, wieviele datensätze eine datenbank anfassen muss, wenn ein indize darüber liegt. und dann wirst du auch sehen, dass datenbanken in aller regel schneller sein werden. und es gibt noch viel mehr eigenschaften, die datenbanken schneller machen, so zum beispiel das cachen von daten, etc. natürlich at auch das betriebsystm einen cache ode reine festplatte. aber dort werden auch andenre operationen ausgeführt, die mit den daten gar nichst zu tun haben. insofern fliegen dort bestimmte informationen der datenbank viel schneller wieder raus, wohingegen die datenbank teilweise gar nicht mehr auf die platte zugreifen muss.

muss auch nur höchstens *einen* Datensatz schreiben, uU sogar nur
einen *Teil* des Datensatzes. Was meinst du, wie eine Datenbank das
macht? Die macht das genau so, nur verallgemeinert.

nein, wie oben beschrieben geht sie anders vor. nimm einen update befehel, die datenbank wird viel schneller wissen, wo sich der datensatz befindet, ergo kann sie auch schneller schreiben. und es gibt sogar noch weitere mechanism. in eine datei muss die änderunng sofort durchgeführt werden. eine datenbank braucht das nicht sofort auf die platte schreiben und trotzdem ist die änderung wirksam.

Indizes sind ein Hinweis für die Datenbank, dass es sich hier lohnen
kann, auf eine andere Art als linear zu suchen. Das heisst, bei einer
eigenen Umgebung brauche ich keine Indizes. Da kann ich selber
entscheiden, wie ich suche. Ob binär, ob per Hash-Index, das bleibt
völlig mir überlassen.

nein, da irrst du dich. ein indize ist nicht immer schneller, zum beispiel wenn ich nur sehr wenige datensätze habe. ABER die entscheidung für einen indize und welchen ist unabhängig davon, ob ich meine eigene "umgebung" benuntze oder nicht. auch bei deiner eigenen umgebung wird in aller regel ein indize viel helfen. und um ihn nutzen zu können, muss ich ihn vorher erstellt haben. und genau das macht eine blosse dateisicherung nicht.

such mal aus 1 millionen datensätze einen bestimmten eintrag ohne
einen solchen indize zu besitzen. eine blosse dateispeicherung wird
das nämlich nicht tun.

Das brauche ich auch nicht.

wen du daten schnell finden willst, warum brauchst du es dann nicht ? sag mal eine begründung, warum du auf den geschwindikeitsvorteil verzichten willst, genau das war ja seine frage ?

und dann wirst du sehen, dass eine datenbank um ein vielfaches
schneller ist.

Nein. Bei einer binären Suche z. B. wird der Aufwand logarithmisch,
da sind maximal ln 1000000 / ln 2 = 20 Vergleiche notwendig.

ohhhh, ich glaube jetzt sehe ich deinen denkfehler. erstens sind eventuell die 20 vergleiche immer noch mehr als über eine datenbank. ABER die daten liegen in keiner sortierung vor, dort liegt dein denkfehler. du muss jeden datensatz anfassen. ohne sortierung geht das nicht und genau das macht ein indize, er bringt eine sortierung rein.

und auch beim schreiben muss eine datenbank nicht immer gleich alle
daten schreiben, sondern eben nur die wirklich neuen,

Dito bei Dateien.

auch das ist falsch. nehmen wir an, er speichert eine bestellung. dazu braucht man in der dateispeicherung alle daten, zum beispiel welche firma bestellt hat mit ihreren gesamten daten. eine datenbank wird diese daten nicht mehr speichern, da sie logische verknüpfungen zwischen den einzelnen entities kennt, die über primär und fremdschlüssel realisiert sin. und die daten der firma wurden enmal aufgenommen und damit ist es gut. natürlich kannst du jetzt auch solche verweise einbauen. aber wie bereits gesagt, dann machst du genau das, was eine datenbank macht, nämlich anfangen logisch einzuteilen, indize zu erstellen, etc.

Wirklich, der einzige Grund, warum man Datenbanken benutzen sollte
ist der, dass wenige Leute das auch noch wirklich so hinkriegen und
es eine Heidenarbeit ist.

ich glaube, du solltest dich ein wenig mehr mit datenbanken auseinander setzten und vor allem mit den hintergründen, warum sie enstanden sind. ansonsten würdest du das nicht sagen.

Ilja

[Christian Kruse]

Hallo Ilja,

Das geht recht problemlos auch mit Dateien.

und genau das geht eben nicht, aus diesem grund gibt es
datenbanken. stell dir mal vor, du hast deine datendateien und
ein programmierer findet nun eine besser möglichkeit daten zu
speichern und wieder abzurufen. dann muss nicht nur er sein
programm ändern, sondern alle anderen programe müssen dies auch
tun.

Das hat ja gar nichts mit der Effizienz zu tun. Dieser Vorteil von
Datenbanken ist unbestritten.

Du hast mich nicht verstanden. Das ist doch gar nicht nötig. Bei
einer fixen Datensatzlänge weiss ich genau, wo ich schreiben oder
lesen muss. Da muss ich immer höchstens *einen* Datensatz lesen,
bei einer Suche etwas mehr (abhängig vom Sortier-Verfahren).

yo, und genau hier setze ich an und zwar ganz genau bei den worten
"etwas mehr". wenn du weisst, wie ein b-Baum oder bitmap indize
funktioniert, dann würde dir das "etwas mehr" viel konkreter
werden.

Glaube mir, ich weiss durchaus, wie Sortier- und Such-Algorithmen
funktionieren.

und es gibt noch viel mehr eigenschaften, die datenbanken
schneller machen, so zum beispiel das cachen von daten, etc.

Diese Caches werden durch den Kommunikations-Overhead locker wieder
aufgeholt.

natürlich at auch das betriebsystm einen cache ode reine
festplatte. aber dort werden auch andenre operationen ausgeführt,
die mit den daten gar nichst zu tun haben. insofern fliegen dort
bestimmte informationen der datenbank viel schneller wieder raus,
wohingegen die datenbank teilweise gar nicht mehr auf die platte
zugreifen muss.

Dafür muss ein (ziemlich komplexer) Interpreter angeworfen werden,
ein Optimizer, etc, pp.

muss auch nur höchstens *einen* Datensatz schreiben, uU sogar nur
einen *Teil* des Datensatzes. Was meinst du, wie eine Datenbank
das macht? Die macht das genau so, nur verallgemeinert.

nein, wie oben beschrieben geht sie anders vor. nimm einen update
befehel, die datenbank wird viel schneller wissen, wo sich der
datensatz befindet, ergo kann sie auch schneller schreiben.

Quatsch. Warum sollte eine DB das schneller wissen?

und es gibt sogar noch weitere mechanism. in eine datei muss die
änderunng sofort durchgeführt werden. eine datenbank braucht das
nicht sofort auf die platte schreiben und trotzdem ist die
änderung wirksam.

Dito Dateien. Gerade auf RAID-Systemen werden Änderungen viel
später geschrieben, als sie in Auftrag gegeben wurde.

Indizes sind ein Hinweis für die Datenbank, dass es sich hier
lohnen kann, auf eine andere Art als linear zu suchen. Das
heisst, bei einer eigenen Umgebung brauche ich keine Indizes.
Da kann ich selber entscheiden, wie ich suche. Ob binär, ob
per Hash-Index, das bleibt völlig mir überlassen.

nein, da irrst du dich.

Wobei?

ein indize ist nicht immer schneller,

Habe ich auch nicht gesagt.

[...] ABER die entscheidung für einen indize und welchen ist
unabhängig davon, ob ich meine eigene "umgebung" benuntze oder
nicht.

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?

auch bei deiner eigenen umgebung wird in aller regel ein indize
viel helfen. und um ihn nutzen zu können, muss ich ihn vorher
erstellt haben. und genau das macht eine blosse dateisicherung
nicht.

Nochmal, langsam zum mitschreiben: Ich brauche keine Indizes. Ich
kann problemlos auch ohne arbeiten.

such mal aus 1 millionen datensätze einen bestimmten eintrag
ohne einen solchen indize zu besitzen. eine blosse
dateispeicherung wird das nämlich nicht tun.

Das brauche ich auch nicht.

wen du daten schnell finden willst, warum brauchst du es dann
nicht ? sag mal eine begründung, warum du auf den
geschwindikeitsvorteil verzichten willst, genau das war ja
seine frage ?

Seine Frage war eine ganz andere als das, was wir hier diskutieren.
Und ich brauche Indizes nicht, weil ich selber bestimme, wie meine
Daten physikalisch organisiert sind. Es gibt durchaus
Speichermethoden, die einem das Suchen ohne Indizes erlauben.

und dann wirst du sehen, dass eine datenbank um ein vielfaches
schneller ist.

Nein. Bei einer binären Suche z. B. wird der Aufwand
logarithmisch, da sind maximal ln 1000000 / ln 2 = 20 Vergleiche
notwendig.

ohhhh, ich glaube jetzt sehe ich deinen denkfehler. erstens sind
eventuell die 20 vergleiche immer noch mehr als über eine datenbank.

Quatsch. Auch eine Datenbank muss sogar uU mehr als 20 Vergleiche
starten, da sie im Normalfall nicht mit Bin-Bäumen sondern mit
B-Trees (Balanced Trees) arbeitet. Du solltest dich echt mal darüber
informieren, wie Datenbanken intern arbeiten. Die kochen auch nur
mit Wasser, auch da hats nur binäre Suchbäume, B-Bäume oder Hash
Tables.

ABER die daten liegen in keiner sortierung vor, dort liegt dein
denkfehler.

Natürlich liegen sie sortiert vor. Ich entscheide, wie die Daten
physikalisch vorliegen, also kann ich sie auch sortiert speichern.

du muss jeden datensatz anfassen.

Nö.

ohne sortierung geht das nicht

Ich bestimme, wie die Daten vorliegen, also kann ich sie auch
sortiert speichern.

und auch beim schreiben muss eine datenbank nicht immer gleich
alle daten schreiben, sondern eben nur die wirklich neuen,

Dito bei Dateien.

auch das ist falsch. nehmen wir an, er speichert eine bestellung.
dazu braucht man in der dateispeicherung alle daten, zum beispiel
welche firma bestellt hat mit ihreren gesamten daten. eine
datenbank wird diese daten nicht mehr speichern, da sie
logische verknüpfungen zwischen den einzelnen entities kennt,
die über primär und fremdschlüssel realisiert sin.

Ja. Und? Glaubst du ernsthaft, dass kann ich nicht auch mit Dateien
so machen?

und die daten der firma wurden enmal aufgenommen und damit ist
es gut. natürlich kannst du jetzt auch solche verweise einbauen.
aber wie bereits gesagt, dann machst du genau das, was eine
datenbank macht, nämlich anfangen logisch einzuteilen, indize
zu erstellen, etc.

Umgekehrt wird ein Schuh draus. Die Datenbank macht das
verallgemeinert, was man früher "zu Fuss" gemacht hat. Und da ich
weiss, wie die Daten aussehen, brauche ich keine Indizes.

Wie gesagt. Der Grund, warum man (unter diesem Gesichtspunkt) eine
Datenbank benutzt, ist die Tatsache, dass es eine Heidenarbeit ist,
das ganze per Fuss zu machen.

Wirklich, der einzige Grund, warum man Datenbanken benutzen sollte
ist der, dass wenige Leute das auch noch wirklich so hinkriegen
und es eine Heidenarbeit ist.

ich glaube, du solltest dich ein wenig mehr mit datenbanken
auseinander setzten und vor allem mit den hintergründen, warum
sie enstanden sind. ansonsten würdest du das nicht sagen.

Dazu muss ich ja nun nichts mehr sagen.

Grüße,
 CK

[Wilhelm Turtschan]

aloha heja he

ich glaube, du solltest dich ein wenig mehr mit datenbanken
auseinander setzten und vor allem mit den hintergründen, warum
sie enstanden sind. ansonsten würdest du das nicht sagen.

Dazu muss ich ja nun nichts mehr sagen.

Schade, jetzt muss ich mir fuer den Nachmittag ein anderes Programm zur Erheiterung einfallen lassen. :-)

man liest sich
Wilhelm

[Ilja]

yo,

und genau das geht eben nicht, aus diesem grund gibt es
datenbanken. stell dir mal vor, du hast deine datendateien und
ein programmierer findet nun eine besser möglichkeit daten zu
speichern und wieder abzurufen. dann muss nicht nur er sein
programm ändern, sondern alle anderen programe müssen dies auch
tun.

Das hat ja gar nichts mit der Effizienz zu tun. Dieser Vorteil von
Datenbanken ist unbestritten.

die frage nach dem sinn von datenbanbken ist aufgekommen, dies oben war die antwort dazu. danach habe ich mich mit der effizienz auseinandergestetzt.

Diese Caches werden durch den Kommunikations-Overhead locker wieder
aufgeholt.

was ich einfach mal anzweifel. auf die festplatte zuzugreifen ist wesentlich langsamer als ein paar overhead anweisungen.

Dafür muss ein (ziemlich komplexer) Interpreter angeworfen werden,
ein Optimizer, etc, pp.

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.

nein, wie oben beschrieben geht sie anders vor. nimm einen update
befehel, die datenbank wird viel schneller wissen, wo sich der
datensatz befindet, ergo kann sie auch schneller schreiben.

Quatsch. Warum sollte eine DB das schneller wissen?

woher willst du den ohne indizierung wissen, welche datenzätze alle angefasst werden müssen, ohne einen full scan durchzuführen ?

Dito Dateien. Gerade auf RAID-Systemen werden Änderungen viel
später geschrieben, als sie in Auftrag gegeben wurde.

aber nur wenn sie über eine batterie pufferung verfügen, ansonsten ist dieser cache auszuschalten, weil es sonst zu inkonsisten im falle eines plattencrash kommt.

Indizes sind ein Hinweis für die Datenbank, dass es sich hier
lohnen kann, auf eine andere Art als linear zu suchen. Das
heisst, bei einer eigenen Umgebung brauche ich keine Indizes.
nein, da irrst du dich.

Wobei?

ob sich ein indize lohnt oder nicht, hat nichts mit einer datenbank oder eigenen lösung zu tun. es kann sich durch aus auch bei einer eigenen lösung lohnen, linear zu suchen.

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?

doch siehe oben. da schreibst du, bei einer eigenen umgebung braucht man keinen indize, sprich keine sortierung und nichts anderes ist ein indize.

Nochmal, langsam zum mitschreiben: Ich brauche keine Indizes. Ich
kann problemlos auch ohne arbeiten.

das würde bedeuten ohne sortierung zu arbeiten, bzw. maximal mit nur einer und dann muss auch jedesmal der gesamte datenbestand sortiert werden, wenn neue einträge hinzukommen oder alte gelöscht werden.

Und ich brauche Indizes nicht, weil ich selber bestimme, wie meine
Daten physikalisch organisiert sind. Es gibt durchaus
Speichermethoden, die einem das Suchen ohne Indizes erlauben.

wo wir wieder bei der datenabhängikeit wären und vor allem, kann sie nur auf eine besttimmte art und weise optimieren. eine datenbank kann dass unterschiedlich.

ohhhh, ich glaube jetzt sehe ich deinen denkfehler. erstens sind
eventuell die 20 vergleiche immer noch mehr als über eine datenbank.

Quatsch. Auch eine Datenbank muss sogar uU mehr als 20 Vergleiche
starten, da sie im Normalfall nicht mit Bin-Bäumen sondern mit
B-Trees (Balanced Trees) arbeitet.

das ist schlicht falsch diese aussage. datenbanken kennen mehr als nur den b-baum, zum beispiel auch einen bitmap indize. es liegt an mir, welchen ich erstellen will.

ABER die daten liegen in keiner sortierung vor, dort liegt dein
denkfehler.

Natürlich liegen sie sortiert vor. Ich entscheide, wie die Daten
physikalisch vorliegen, also kann ich sie auch sortiert speichern.

na klar, und wenn neue daten dazu kommen, geändert oder gelöscht werden, dann sortierst du einfach mal so nebenbei den gesamten datenbestand gleich immer mit. aber egal, ich werde dir eine einfach aufgabe stellen, die du mit deiner methode nicht lösen wirst. was ist, wenn du eine sortierung über den nachnamen brauchst, aber auch eine über den ort einer person. damit hättest du zwei unterschiedliche sortierungen, könntest aber nur eine physikalisch abbilden, es sei denn, du speichert die kompletten daten zweimal ab oder aber du führst indize ein, wo wir wieder bei datenbanken sind und warum sie effektiver arbeiten.

du muss jeden datensatz anfassen.

Nö.

ohne sortierung geht das nicht

Ich bestimme, wie die Daten vorliegen, also kann ich sie auch
sortiert speichern.

und genau das wirst du nicht schaffen, sobald es mehere sortierungen gibt und ich bezweifel, dass du die erste sortierung mit rein bringst bei einer laufenden datenbank, wo sich datenbestände ändern. und dann fässt du alle an.

und auch beim schreiben muss eine datenbank nicht immer gleich
alle daten schreiben, sondern eben nur die wirklich neuen,

Dito bei Dateien.

wie soll das gehen, jemand ändert daten, die dann aber nicht festgeschrieben werden und ein anderer greift auf die daten zu und dort sind sie nicht aktuell, da im gegensatz zu datenbanken hier direkt auf die dateien zugefriffen wird. eine datendank kann dies aber abfagen, da dort nicht diekt zugegriffen wird.

auch das ist falsch. nehmen wir an, er speichert eine bestellung.
dazu braucht man in der dateispeicherung alle daten, zum beispiel
welche firma bestellt hat mit ihreren gesamten daten. eine
datenbank wird diese daten nicht mehr speichern, da sie
logische verknüpfungen zwischen den einzelnen entities kennt,
die über primär und fremdschlüssel realisiert sin.

Ja. Und? Glaubst du ernsthaft, dass kann ich nicht auch mit Dateien
so machen?

nein, kannst du nicht es sei den, du machst genau das, was eine datenbank nun mal machen muss, um das zu erreichen. aber dann haben wir ja eben ein DBMS.

Umgekehrt wird ein Schuh draus. Die Datenbank macht das
verallgemeinert, was man früher "zu Fuss" gemacht hat. Und da ich
weiss, wie die Daten aussehen, brauche ich keine Indizes.

nein, eine datenbank macht wesentlich mehr, als man früher in der lage war zu tun.

Wie gesagt. Der Grund, warum man (unter diesem Gesichtspunkt) eine
Datenbank benutzt, ist die Tatsache, dass es eine Heidenarbeit ist,
das ganze per Fuss zu machen.

nein wie bereits oben gesagt und von dir auch nicht angezweifelt ging es primär um datenunabhängigkeit.

Ilja

[Christian Kruse]

Hallo Ilja,

zuerst mal: es heisst der Index und die Indizes ;-)

Diese Caches werden durch den Kommunikations-Overhead locker
wieder aufgeholt.

was ich einfach mal anzweifel. auf die festplatte zuzugreifen ist
wesentlich langsamer als ein paar overhead anweisungen.

*g* Du solltest dich darüber informieren, wie Netzwerk-Anwendungen
funktionieren und wie der Overhead hier definiert ist. Erstens macht
die Anbindung und zweitens die Abstraktion über das Protokoll das
ganze ziemlich teuer. Und jetzt komm mir nicht mit UNIX Domain
Sockets, auch hier ist der Protokoll-Overhead extrem teuer -- und
zu diesem Protokoll-Overhead kommt der HD-Overhead (sic!) hinzu.
Glaube mir, hier weiss ich, wovon ich rede.

Dafür muss ein (ziemlich komplexer) Interpreter angeworfen werden,
ein Optimizer, etc, pp.

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?

nein, wie oben beschrieben geht sie anders vor. nimm einen
update befehel, die datenbank wird viel schneller wissen, wo
sich der datensatz befindet, ergo kann sie auch schneller
schreiben.

Quatsch. Warum sollte eine DB das schneller wissen?

woher willst du den ohne indizierung wissen, welche datenzätze alle
angefasst werden müssen, ohne einen full scan durchzuführen ?

Herjemine. Sortierte Daten halt. Warum sollte es langsamer sein?

Dito Dateien. Gerade auf RAID-Systemen werden Änderungen viel
später geschrieben, als sie in Auftrag gegeben wurde.

aber nur wenn sie über eine batterie pufferung verfügen, ansonsten
ist dieser cache auszuschalten, weil es sonst zu inkonsisten im
falle eines plattencrash kommt.

Im Falle eines Stromausfalls meinst du.

Indizes sind ein Hinweis für die Datenbank, dass es sich hier
lohnen kann, auf eine andere Art als linear zu suchen. Das
heisst, bei einer eigenen Umgebung brauche ich keine Indizes.
nein, da irrst du dich.

Wobei?

ob sich ein indize lohnt oder nicht, hat nichts mit einer
datenbank oder eigenen lösung zu tun. es kann sich durch aus
auch bei einer eigenen lösung lohnen, linear zu suchen.

Sorry, aber ich glaube, du bist ein bisschen verwirrt und/oder hast
gar nicht verstanden, was ich dir sagen will.

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?

doch siehe oben. da schreibst du, bei einer eigenen umgebung
braucht man keinen indize, sprich keine sortierung und nichts
anderes ist ein indize.

Eben. Ich brauche keinen Index bei sortierten Daten.

Nochmal, langsam zum mitschreiben: Ich brauche keine Indizes. Ich
kann problemlos auch ohne arbeiten.

das würde bedeuten ohne sortierung zu arbeiten, bzw. maximal mit
nur einer

Ja.

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?

Und ich brauche Indizes nicht, weil ich selber bestimme, wie meine
Daten physikalisch organisiert sind. Es gibt durchaus
Speichermethoden, die einem das Suchen ohne Indizes erlauben.

wo wir wieder bei der datenabhängikeit wären und vor allem, kann
sie nur auf eine besttimmte art und weise optimieren. eine
datenbank kann dass unterschiedlich.

Ich auch, wenn ich das möchte. Da wären dann allerdings Indizes
sinnvoll.

ohhhh, ich glaube jetzt sehe ich deinen denkfehler. erstens sind
eventuell die 20 vergleiche immer noch mehr als über eine
datenbank.

Quatsch. Auch eine Datenbank muss sogar uU mehr als 20 Vergleiche
starten, da sie im Normalfall nicht mit Bin-Bäumen sondern mit
B-Trees (Balanced Trees) arbeitet.

das ist schlicht falsch diese aussage. datenbanken kennen mehr
als nur den b-baum,

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.

ABER die daten liegen in keiner sortierung vor, dort liegt dein
denkfehler.

Natürlich liegen sie sortiert vor. Ich entscheide, wie die Daten
physikalisch vorliegen, also kann ich sie auch sortiert speichern.

na klar, und wenn neue daten dazu kommen, geändert oder gelöscht
werden, dann sortierst du einfach mal so nebenbei den gesamten
datenbestand gleich immer mit.

Lies am besten mal ein gutes Buch über Algorithmen und
Datenstrukturen.

aber egal, ich werde dir eine einfach aufgabe stellen, die du mit
deiner methode nicht lösen wirst. was ist, wenn du eine
sortierung über den nachnamen brauchst, aber auch eine über den
ort einer person. damit hättest du zwei unterschiedliche
sortierungen, könntest aber nur eine physikalisch abbilden,
es sei denn, du speichert die kompletten daten zweimal ab
oder aber du führst indize ein, wo wir wieder bei datenbanken
sind und warum sie effektiver arbeiten.

[ ] 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.
Dafür wird sie auch immer *viel* mehr Arbeit und höhere
Fehleranfälligkeit bedeuten.

und auch beim schreiben muss eine datenbank nicht immer
gleich alle daten schreiben, sondern eben nur die wirklich
neuen,

Dito bei Dateien.

wie soll das gehen, jemand ändert daten, die dann aber nicht
festgeschrieben werden

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?

eine datendank kann dies aber abfagen, da dort nicht diekt
zugegriffen wird.

Stell dir vor, es gibt auch DBMS, die *nicht* mit SQL und/oder als
Server-System arbeiten.

auch das ist falsch. nehmen wir an, er speichert eine
bestellung. dazu braucht man in der dateispeicherung alle
daten, zum beispiel welche firma bestellt hat mit ihreren
gesamten daten. eine datenbank wird diese daten nicht mehr
speichern, da sie logische verknüpfungen zwischen den
einzelnen entities kennt, die über primär und fremdschlüssel
realisiert sin.

Ja. Und? Glaubst du ernsthaft, dass kann ich nicht auch mit
Dateien so machen?

nein, kannst du nicht es sei den, du machst genau das, was eine
datenbank nun mal machen muss, um das zu erreichen. aber dann
haben wir ja eben ein DBMS.

Nein, wir haben eine _spezialisierte_ Form eines DBMS.

Umgekehrt wird ein Schuh draus. Die Datenbank macht das
verallgemeinert, was man früher "zu Fuss" gemacht hat. Und da ich
weiss, wie die Daten aussehen, brauche ich keine Indizes.

nein, eine datenbank macht wesentlich mehr, als man früher in der
lage war zu tun.

Quatsch. Ich habe dir schon einmal erklärt, dass auch Datenbanken nur
mit Wasser kochen.

Wie gesagt. Der Grund, warum man (unter diesem Gesichtspunkt) eine
Datenbank benutzt, ist die Tatsache, dass es eine Heidenarbeit
ist, das ganze per Fuss zu machen.

nein wie bereits oben gesagt

Du hast mir oben nur bewiesen, dass dir ein Grundverständnis der
entsprechenden Algorithmen und Arbeitsweisen fehlt.

und von dir auch nicht angezweifelt ging es primär um
datenunabhängigkeit.

Datenunabhängigkeit? Ich denke mal, du meinst damit die Abstraktion
der Zugriffsmethode und die damit fehlenden Probleme der Anpassung.

Grüße,
 CK

[Ilja]

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

[Daniela Koller]

Hi Ilja

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.

Nein, genau eben nicht. Christian redet die ganze Zeit von sehr genau definierten Daten. Da kann man sehr wohl Zugriffsmethoden wählen die in jedem Fall die besten sind.

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.

Nein, du hast die Voraussetzungen für Christians Ansatz nicht gelesen. Wie die Daten genau aussehen und welcher Algorithmus dafür optimal ist, steht fest weil es klar ist wie die Daten aussehen.

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.

Wiederum Voraussetzungsfrage. Daten können sehr wohl immer sortiert vorliegen wenn es die Applikation so vorgibt und es sich natürlich ergibt.

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.

Nein, kommt sehr auf die Anwendungen drauf an. Logdaten zb brauche ich nur in der zeitlichen Auswertung, einen Index für ein Buch hingegen nur in der alphabetischen.

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.

Diese Mechanismen haben nichts mit DBMS zu tun sondern sind ganz gewöhnliche Baumalgorithmen...

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.

Jein, DBMS müssen diese Algorithmen abstrakter implementieren als es einem Entwickler möglich wäre, der etwas nur für eine genau spezifizierte Datenmenge und Datenart braucht.

[ ] 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.

Falsch, jede einzelne dieser Optimierungen kann man auch angepasst an die Daten implementieren. Ob das sinnvoll ist, kommt auf den Anwendungsbereich und die Daten 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.

Jein, wiederum kommt es sehr auf die Daten und den Anwendungszweck an ob es effektiver ist. Das ist der Unterschied btw zwischen einem Datenarchitekten und einem Datenbank- oder XML-Architekten. Der Datenarchitekt entscheidet anhand der Anwendung und der Daten was für den jeweiligen Fall die beste Lösung unter Berücksichtigung was in Zukunft mit den Daten und der Anwendung passieren kann an Änderungen und Ausbauten.

doch genau das war meine aussage. dbms müssen änderungen nicht sofort auf platte schreiben, du musst das tun.

Doch, müssen sie, was glaubst du wo Transaktionslogs und solche Spässchen liegen?

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.

Das ist einfach nur Humbug. Zu Absolut, zu nichtssagend. Beides hat Vor- und Nachteile die es genau gegeneinander abzuwägen gilt.

Gruss Daniela

[Ilja]

yo,

Nein, genau eben nicht. Christian redet die ganze Zeit von sehr genau definierten Daten. Da kann man sehr wohl Zugriffsmethoden wählen die in jedem Fall die besten sind.

falsch, bei gleicher detanstruktur kann ein und derselbe algorithmus gut oder schlecht sein, je nachdem wieviele datensätze ich besitze und dann auch noch in abhängigkeit davon, welche daten drinne stehen. wenn das nicht klar ist, warum das so ist, lege ich es gerne da.

Nein, du hast die Voraussetzungen für Christians Ansatz nicht gelesen. Wie die Daten genau aussehen und welcher Algorithmus dafür optimal ist, steht fest weil es klar ist wie die Daten aussehen.

siehe oben. es stehn aber immer nur die strukturen fest, nicht aber wieviele datensätze ich besitze und welche daten. dass ist aber sehr wichtig für die optimierung.

Wiederum Voraussetzungsfrage. Daten können sehr wohl immer sortiert vorliegen wenn es die Applikation so vorgibt und es sich natürlich ergibt.

dann zeige mir doch mal, wie mehr als eine sortierungen nur mit hilfe einer datendatei physisch dargestellt werden. das geht nämlich nicht.

Nein, kommt sehr auf die Anwendungen drauf an. Logdaten zb brauche ich nur in der zeitlichen Auswertung, einen Index für ein Buch hingegen nur in der alphabetischen.

nein, die frage der sortierung beruht darauf, wie die daten abgerufen werden. und abfragen gibt es in der unterschiedlichsten form. deine eine will datensätze haben, die in einem zeitraum liegen und der andere will die daten nach einem bestimmten namen abfragen. dies würde zwei sortierungen benötigen, wenn nicht ein full scan durchgeführt werden soll.

Jein, DBMS müssen diese Algorithmen abstrakter implementieren als es einem Entwickler möglich wäre, der etwas nur für eine genau spezifizierte Datenmenge und Datenart braucht.

und das ist ein denkfehler, wie weiter oben beschrieben. selbst bei nur einer datenstruktur muss man auch allgemein programmieren, um den besten auszuführen, da man ja nicht bei der programmierung den inhalt und die anzahl der daten kennt.

Falsch, jede einzelne dieser Optimierungen kann man auch angepasst an die Daten implementieren. Ob das sinnvoll ist, kommt auf den Anwendungsbereich und die Daten an.

nein, hast du mehrere benutzer/programme, die auf die daten zugreifen, dann musst man die datenänderungen immer sofort festschreiben. ein dbms muss das nicht. das ist ganz unzweifelhaft ein vorteil, den man ohne dbms nicht kann.

doch genau das war meine aussage. dbms müssen änderungen nicht sofort auf platte schreiben, du musst das tun.

Doch, müssen sie, was glaubst du wo Transaktionslogs und solche Spässchen liegen?

nö, ein dmbs schreibt daten nicht sofort auf die platte, wenn eine tranksaktion abgeschlossen ist. dies geschieht zum beispiel erst be einem checkpoint.

Ilja

[Daniela Koller]

Hi Ilja

Bevor du weiterliest, Anwendung meint in diesem Text immer der Nutzen, Zweck, Anwendung der Daten. Also nicht Programm sondern globaler gesehen.

Nein, genau eben nicht. Christian redet die ganze Zeit von sehr genau definierten Daten. Da kann man sehr wohl Zugriffsmethoden wählen die in jedem Fall die besten sind.

falsch, bei gleicher detanstruktur kann ein und derselbe algorithmus gut oder schlecht sein, je nachdem wieviele datensätze ich besitze und dann auch noch in abhängigkeit davon, welche daten drinne stehen. wenn das nicht klar ist, warum das so ist, lege ich es gerne da.

Daten beinhaltet nicht nur Datenstruktur sondern auch Datenmenge und ein Haufen anderer Sachen. Wenn ich Datenstruktur meine, dann schreibe ich Datenstruktur.

Wiederum Voraussetzungsfrage. Daten können sehr wohl immer sortiert vorliegen wenn es die Applikation so vorgibt und es sich natürlich ergibt.

dann zeige mir doch mal, wie mehr als eine sortierungen nur mit hilfe einer datendatei physisch dargestellt werden. das geht nämlich nicht.

Es gibt Daten die verlangen nur nach einer Sortierung.

nein, die frage der sortierung beruht darauf, wie die daten abgerufen werden. und abfragen gibt es in der unterschiedlichsten form. deine eine will datensätze haben, die in einem zeitraum liegen und der andere will die daten nach einem bestimmten namen abfragen. dies würde zwei sortierungen benötigen, wenn nicht ein full scan durchgeführt werden soll.

Nein, eben genau nicht, das ist genau die Voraussetzung. Nicht alle Daten wollen nach unterschiedlichen Kriterien gefiltert werden. Die Anwendung der Daten schreibt vor ob überhaupt und wie gefiltert werden kann.

und das ist ein denkfehler, wie weiter oben beschrieben. selbst bei nur einer datenstruktur muss man auch allgemein programmieren, um den besten auszuführen, da man ja nicht bei der programmierung den inhalt und die anzahl der daten kennt.

Doch, es gibt Anwendungen, da hat man sehr genaue Informationen über die Daten, inklusive Mengen, Arten, Beziehungen, genaue Datenstrukturen... (Falls dir noch was einfällt was bei Daten variabel sein kann, auch das kann bekannt sein)

nein, hast du mehrere benutzer/programme, die auf die daten zugreifen, dann musst man die datenänderungen immer sofort festschreiben. ein dbms muss das nicht. das ist ganz unzweifelhaft ein vorteil, den man ohne dbms nicht kann.

Nein, die habe ich nicht zwangsläufig. Die Daten und Anwendungen schreiben mir das evtl vor, evtl aber auch nicht.
Warum schreibst du mir viele Benutzer vor wenn meine Anwendung die per Definition nicht haben kann?

Doch, müssen sie, was glaubst du wo Transaktionslogs und solche Spässchen liegen?

nö, ein dmbs schreibt daten nicht sofort auf die platte, wenn eine tranksaktion abgeschlossen ist. dies geschieht zum beispiel erst be einem checkpoint.

Ehm, was glaubst du was ein Checkpoint ist? Achja, der Abschluss der Transaktion. Und wo liegen die Änderung die innerhalb einer Transkation geschrieben werden? Ja, auf der HD, weil nur dann kann man Rollforwards und Rollbacks machen wenn ein kleineres Malheur passiert. Btw schreiben Datenbanken manchmal auch direkt in die Datenbank und halten unfertige Transaktionen in Form von Rollback-Logs fest und Rollen sie zurück falls die Transaktion fehlschlägt. Hängt auch sehr vom DBMS ab und auch von den Einstellungen am DBMS ab.

Weist du was das Problem ist? Du schreibst allen Anwendungen vor, die Fähigkeiten eines DBMS zu benötigen. Das ist aber nicht so. Ob ein volles DBMS benötigt wird, sagen nur die Daten und die Anwendung aus. Wenn nur minimalste Teile eines DBMS benötigt werden weil die Anwendung einfach nicht mehr braucht und auch nicht mehr brauchen wird, dann ist es manchmal auch sinnvoller, nur diese kleinsten Teile zu schreiben die man braucht.

Gruss Daniela

[Ilja]

yo,

Nein, genau eben nicht. Christian redet die ganze Zeit von sehr genau definierten Daten. Da kann man sehr wohl Zugriffsmethoden wählen die in jedem Fall die besten sind.

falsch, bei gleicher detanstruktur kann ein und derselbe algorithmus gut oder schlecht sein, je nachdem wieviele datensätze ich besitze und dann auch noch in abhängigkeit davon, welche daten drinne stehen. wenn das nicht klar ist, warum das so ist, lege ich es gerne da.

Daten beinhaltet nicht nur Datenstruktur sondern auch Datenmenge und ein Haufen anderer Sachen. Wenn ich Datenstruktur meine, dann schreibe ich Datenstruktur.

und was ist dann an den daten zitat "genau definierten Daten" ? die dateninhalte und anzahl der daten ist doch flexibel, ändert sich ständig. wie soll ich darauf rücksicht nehmen, wenn ich das programm schreibe, wo ich doch noch gar nicht weiss, welche daten reinkomen werden ?

Es gibt Daten die verlangen nur nach einer Sortierung.

und was machst du, wenn mein programm nun zwei sortierungen verlangt, wenn das eine vorgabe ist ?

Nein, eben genau nicht, das ist genau die Voraussetzung. Nicht alle Daten wollen nach unterschiedlichen Kriterien gefiltert werden. Die Anwendung der Daten schreibt vor ob überhaupt und wie gefiltert werden kann.

das ist doch schlecht, wenn ich als benutzer daran gebunden bin, mich nach dem programm zu richten, obwohl ich gerne was anderes hätte.

Doch, es gibt Anwendungen, da hat man sehr genaue Informationen über die Daten, inklusive Mengen, Arten, Beziehungen, genaue Datenstrukturen... (Falls dir noch was einfällt was bei Daten variabel sein kann, auch das kann bekannt sein)

wir reden hier aber von OLTP datenbanken. solche statischen datenbank kommen recht selten vor, bzw. abei handelt es sich in allre regel um abgeschlossene geschäftsjahre, wo data mining betrieben wird. dies funktioniert aber nun ganz anders. dort werden die daten wiederum nicht datensatz nach datensatz gespeichert. du verstrickst dich da immer weiter in spezialfällen, die mit der praxis gar nichts mehr gemeinsam haben.

Nein, die habe ich nicht zwangsläufig. Die Daten und Anwendungen schreiben mir das evtl vor, evtl aber auch nicht.
Warum schreibst du mir viele Benutzer vor wenn meine Anwendung die per Definition nicht haben kann?

wiedr speziallfall. di regel ist, mehrere benutzer/programme arbeiten an den daten gleichzeitig.

Ehm, was glaubst du was ein Checkpoint ist? Achja, der Abschluss der Transaktion.

ein checkpoint ist kein abschluss einer transaktion, sie werden auch gesetzt wenn keine transaktionen durchgeführt werden. des weiteren sind transaktionen auch ohne einen checkpoint abgeschlossen, da sie sichin den redo dateien befinden. fällt ein dbms aus, bevor ein checkpoint gesetzt wurde aber schon bei abgeschlossener transaktion, ist das dbms durchaus in der lage, diese transaktion auszuführen. ein checkpoint ist also kein abschluss einer transaktion. ein checkpoint schreibt daten vom cache in die datendateien.

Und wo liegen die Änderung die innerhalb einer Transkation geschrieben werden? Ja, auf der HD, weil nur dann kann man Rollforwards und Rollbacks machen wenn ein kleineres Malheur passiert.

nein, nicht alle änderungen der daten liegen auch in den datendateien auf der festplatte. ein teil befindet sich in den redo dateien, die jeweils die anweisungen enthalten, aber keine daten an sich.

Weist du was das Problem ist? Du schreibst allen Anwendungen vor, die Fähigkeiten eines DBMS zu benötigen. Das ist aber nicht so. Ob ein volles DBMS benötigt wird, sagen nur die Daten und die Anwendung aus. Wenn nur minimalste Teile eines DBMS benötigt werden weil die Anwendung einfach nicht mehr braucht und auch nicht mehr brauchen wird, dann ist es manchmal auch sinnvoller, nur diese kleinsten Teile zu schreiben die man braucht.

ok, sagen wir nur ein benutzer greift auf die daten zu, die daten stehen alle schon vor der programmierung fest, ändern sich also nicht und es darf maximal über eine sortierung gesucht werden. desweiteren weiss man, dass sich die strukturen und dateninhalte nie ändern werden und auch in zukunft die daten von nur einem programm und nur einer person zur gleichen zeit genutzt werden. dann gebe ich dir recht, dann braucht man kein dbms. und nun überlge mal, ob das sinn macht.

Ilja

[Daniela Koller]

und was ist dann an den daten zitat "genau definierten Daten" ? die dateninhalte und anzahl der daten ist doch flexibel, ändert sich ständig. wie soll ich darauf rücksicht nehmen, wenn ich das programm schreibe, wo ich doch noch gar nicht weiss, welche daten reinkomen werden ?

Nein, ist sie nicht zwingend. Beispielsweise kann eine Applikation definieren, ich brauche immer nur die 10 (von mir aus auch 10000) letzten Einträge, die alten müssen nicht gespeichert werden weil uninteressant, und ich brauche sie in der Reihenfolge wie sie reinkommen und immer alle. Ich weis also, es sind alles Einträge von der Form, sie haben keinerlei Verbindung zueinander und es sind höchstens so viele. Das ist für die Zugriffsmethode genau genug, sequentielles Lesen ist da angesagt, in absolut jedem Fall.

Es gibt Daten die verlangen nur nach einer Sortierung.

und was machst du, wenn mein programm nun zwei sortierungen verlangt, wenn das eine vorgabe ist ?

Abwägen ob es immernoch sinnvoller ist, etwas selber zu implementieren oder nicht. Wenn nicht ein DBMS benutzen. Meine Daten müssen das jetzt aber nicht sein. Willst du es meiner Applikation und meinen Daten deswegen verbieten, kein DBMS zu benutzen weil deine Applikation mit anderen Daten ein DBMS benötigt?

das ist doch schlecht, wenn ich als benutzer daran gebunden bin, mich nach dem programm zu richten, obwohl ich gerne was anderes hätte.

Du als Benutzer willst das nicht, die Daten sind so, wie es die Natur vorsieht. Es gibt nicht für alle Daten der Welt mehrere Sichten. Es gibt sie für diesen angenommenen (und in der realen Welt durchaus auch existenten Fall) einfach nicht.

Es gibt nicht nur Daten die beliebig gefiltert werden können.

Doch, es gibt Anwendungen, da hat man sehr genaue Informationen über die Daten, inklusive Mengen, Arten, Beziehungen, genaue Datenstrukturen... (Falls dir noch was einfällt was bei Daten variabel sein kann, auch das kann bekannt sein)

wir reden hier aber von OLTP datenbanken. solche statischen datenbank kommen recht selten vor, bzw. abei handelt es sich in allre regel um abgeschlossene geschäftsjahre, wo data mining betrieben wird.

Nein, wir reden nicht von OLTP Datenbanken, genauso wenig von statistischen Datenbanken. Wir reden davon, das es Daten gibt, die von Natur aus klar definiert sind und die aus ihrer Natur heraus genau definiert sind und auch in ihrer Reihenfolge und ihrem Nutzen. Das dies nur ein begrenzter Teil der Daten ist, ist klar. Es spielt auch keinerlei Rolle wie selten dieser Fall ist. Er ist existent und häufig genug dass man nicht zwangsweise mit Datenbanken darauf zugreifen muss weil es grundsätzlich böse wäre, etwas anderes zu benutzen. Das einzige was ich und auch Christian dir begreiflich machen wollen, ist, das es nicht nur Datenbanken gibt und das Datenbanken nicht immer die ideale Lösung darstellen. Weder er noch ich behaupten, Datenbanken seinen immer oder meistens oder wie häufig auch immer die schlechtere Lösung. Sie sind nur auch nicht immer sie bessere Lösung.

dies funktioniert aber nun ganz anders. dort werden die daten wiederum nicht datensatz nach datensatz gespeichert. du verstrickst dich da immer weiter in spezialfällen, die mit der praxis gar nichts mehr gemeinsam haben.

Ich denke, ich habe genug praktische Erfahrung um reichlich mit Daten gearbeitet zu haben, wo Datenbanken nicht die ideale Lösung sind. Genauso gibt es Daten, idealerweise in Datenbanken gehalten wird und ein anderer Teil in Files. Ich habe auch mit reichlich Daten gearbeitet, wo Datenbanken die ideale Lösung waren, aber deswegen muss ich doch nicht Datenbanken einsetzen, wo ich effizienter mit anderen Zugriffsmethoden arbeiten kann. Gerade ein Logfile ist so ein Fall wo ich es nicht in Datenbanken packen würde solange ich nur die zeitliche Auswertung brauche. Bei Logfiles ist das auch der Normalfall das ich nur diese Auswertung brauche. Wenn mein PC Ärger macht, dann schau ich ins Fehlerlog rein und fange unten an zu lesen. Ich habe da nicht das geringste andere Interesse daran. Wenn jetzt hingegen ein Statistiker kommt und diese Daten liest, ist er an anderem interessiert, aber muss ich als PC-Besitzer dafür eine Methode wählen, die für mich weniger optimal ist (Bevor du widersprichst, ich habe keine Lust dir mit einem Haufen Mathe und Assembler und so zu beweisen dass es das ist).

Nein, die habe ich nicht zwangsläufig. Die Daten und Anwendungen schreiben mir das evtl vor, evtl aber auch nicht.
Warum schreibst du mir viele Benutzer vor wenn meine Anwendung die per Definition nicht haben kann?

wiedr speziallfall. di regel ist, mehrere benutzer/programme arbeiten an den daten gleichzeitig.

Nein, ist es nicht, vielleicht in deinem Umfeld. Müssen deswegen alle meine Programme Datenbanken benutzen obwohl es nicht nötig ist?

Ehm, was glaubst du was ein Checkpoint ist? Achja, der Abschluss der Transaktion.

ein checkpoint ist kein abschluss einer transaktion, sie werden auch gesetzt wenn keine transaktionen durchgeführt werden. des weiteren sind transaktionen auch ohne einen checkpoint abgeschlossen, da sie sichin den redo dateien befinden. fällt ein dbms aus, bevor ein checkpoint gesetzt wurde aber schon bei abgeschlossener transaktion, ist das dbms durchaus in der lage, diese transaktion auszuführen. ein checkpoint ist also kein abschluss einer transaktion. ein checkpoint schreibt daten vom cache in die datendateien.

Oracle hat ein Haufen Begriffe, inklusive dem der Datenbank neu (falsch im Vergleich mit der Datenbanktheorie) definiert. Wenn du von der Oraclespezifischen Definition redest, musst du das sagen, ansonsten geh ich von der Definition aus, wie sie die Datenbanktheorie vorgibt.

Und wo liegen die Änderung die innerhalb einer Transkation geschrieben werden? Ja, auf der HD, weil nur dann kann man Rollforwards und Rollbacks machen wenn ein kleineres Malheur passiert.

nein, nicht alle änderungen der daten liegen auch in den datendateien auf der festplatte. ein teil befindet sich in den redo dateien, die jeweils die anweisungen enthalten, aber keine daten an sich.

Die Anweisungen enthalten die neuen Daten. Spielt also keine Rolle ob Anweisungen oder Daten gespeichert wird. Oracle macht es so wie du sagst, andere DBMS wieder anders...

Weist du was das Problem ist? Du schreibst allen Anwendungen vor, die Fähigkeiten eines DBMS zu benötigen. Das ist aber nicht so. Ob ein volles DBMS benötigt wird, sagen nur die Daten und die Anwendung aus. Wenn nur minimalste Teile eines DBMS benötigt werden weil die Anwendung einfach nicht mehr braucht und auch nicht mehr brauchen wird, dann ist es manchmal auch sinnvoller, nur diese kleinsten Teile zu schreiben die man braucht.

ok, sagen wir nur ein benutzer greift auf die daten zu, die daten stehen alle schon vor der programmierung fest, ändern sich also nicht und es darf maximal über eine sortierung gesucht werden. desweiteren weiss man, dass sich die strukturen und dateninhalte nie ändern werden und auch in zukunft die daten von nur einem programm und nur einer person zur gleichen zeit genutzt werden. dann gebe ich dir recht, dann braucht man kein dbms. und nun überlge mal, ob das sinn macht.

Ich habe nicht von Dateninhalten geredet...

Gruss Daniela

[Ilja]

yo,

ich denke mal, wir sollten eins klären, da du es aus irgend einem grund immer wieder mit anführst. ich schreibe niemanden vor, was er tun sollte. jemand hat gefragt, ich habe meine meinung zum besten gegeben. nicht ich habe die meinung eines anderen angezweifelt, sondern umgekehrt, hat christian die diskussion ins rollen gebracht, worüber ich auch in keinster weise böse bin. nur eben meine meinung und standpunkte würde ich gerne vertreten können. insofern macht es wenig sinn, das als argumentationsmittel immer wieder aufzuführen, ich schreibe angeblich anderen etwas vor.

ausserdem habe ich keine zweifel an deiner person oder fähigkeiten. sie mögen gerne meine um ein vielfaches übertreffen. du stellst dich da in eine opferhaltung, die nichts mit meinen aussagen zu tun habe, sondern ein schlechter argumentationsstil ist.

des weiteren ist von speziallfällen wie du sie konstruierst nicht die rede. er hat gefragt, was ist besser. er hat zwei unterschiedliche meinungen gehört und meine steht immer noch, ich würde in keinem betrieb ohne eine datenbank arbeiten weil es:

1. in vielen fällen einfacher umzusetzen ist, als die programmierung selbst vornehmen zu müssen.

2. ich datenunabhängikeit erhalte, was für mich mittelbar oder in der zukunft wichtig ist. und wie der name zukunft schon sagt, man kennt sie nicht. so kann ich auch sicherstellen, dass unterschiedliche pogramme diese daten nutzen können.

3. ein dbms bei nicht statischen daten schneller ist.

4. es eine sehr einfache benutzerverwaltung der daten gibt, so dass nicht jeder alle daten sehen/ändern kann, sondern nur die gewünschten

die diskussion über den sinn von datenbanken gab es meiner meinung schon vor jahren, wo man die notwendigkeit erkannt hat und schließlich angefangen hat, dbms zu entwickeln. nartürlich sei jedem eine andere ansicht darüber gegönnt. besonders cräcks, die alles viel besser können, für die es quasi nur ein schnippsen mit den finger bedeutet, das alles umzusetzen, die der meinung sind, die kochen ja alle eh nur mit wasser, bitte sehr. ich für meinen teil würde ein dbms benutzen, solange es sich nicht um private daten handelt.

Wir reden davon, das es Daten gibt, die von Natur aus klar definiert sind und die aus ihrer Natur heraus genau definiert sind und auch in ihrer Reihenfolge und ihrem Nutzen.

lass mal die natur aus dem spiel, die ist nämlich auch wie die daten unabhängig. das problem der datei verwaltung der daten ist, dass man anfangs mit den gleichen ansätzen rangegangen ist, wie du nun auch argumentierst. man hatte feste strukturen und dachte, dass läßt sich doch wunderbar abbilden. das war aber sehr kurzsichtig, wie sich später herausgestellt hat. die unternehmen sind nämlich gewachsen oder haben sich verändert und somit haben sich auch die strukturen verändert. und genau das hat zu problemen geführt, dass sich ein unternehmen "der natur den daten" anpasen mussten. und daraus hat man gelernt, dass an eben nicht weiss, dass strukturen immer so bleiben, wie sie sind und genau aus diesem grund gibt es dbms.

Oracle hat ein Haufen Begriffe, inklusive dem der Datenbank neu (falsch im Vergleich mit der Datenbanktheorie) definiert. Wenn du von der Oraclespezifischen Definition redest, musst du das sagen, ansonsten geh ich von der Definition aus, wie sie die Datenbanktheorie vorgibt.

ein checkpoint ist auch unter mssql kein abschluss einer transaktion. was du meinst ist ein commit befehl.

Die Anweisungen enthalten die neuen Daten. Spielt also keine Rolle ob Anweisungen oder Daten gespeichert wird. Oracle macht es so wie du sagst, andere DBMS wieder anders...

so weit ich es weiss arbeiten alle dbms so, dass sie erst die log-dateien schreiben und dann später die daten-dateien ändern. es wäre schwierig anders umzusetzen. im falle eines fehlers muss ein logeintrag vorhanden sein, bevor daten-dateien geändert wurden. dies macht auch einen vorteil des dbms gegenüber dem datei-zugriff deutlich. bevor datenblöcke wieder auf die festplatte geschrieben werden, können mehrere tranasktionn auf die gleichen datensätze ausgeführt wprden sein und trotzdem schreibt er den entgültigen datensatz nur einmal auf die platte und nicht mehrmals.

Ilja

[Daniela Koller]

yo,

ich denke mal, wir sollten eins klären, da du es aus irgend einem grund immer wieder mit anführst. ich schreibe niemanden vor, was er tun sollte. jemand hat gefragt, ich habe meine meinung zum besten gegeben. nicht ich habe die meinung eines anderen angezweifelt, sondern umgekehrt, hat christian die diskussion ins rollen gebracht, worüber ich auch in keinster weise böse bin. nur eben meine meinung und standpunkte würde ich gerne vertreten können. insofern macht es wenig sinn, das als argumentationsmittel immer wieder aufzuführen, ich schreibe angeblich anderen etwas vor.

Stimmt, du schreibst nicht vor, du sagst nur, sie wären in jedem Fall suboptimal.

1. in vielen fällen einfacher umzusetzen ist, als die programmierung selbst vornehmen zu müssen.

Ja, in vielen, aber nicht in allen, inklusive in dem Fall nicht (solange er nicht eine spezielle Nutzung der Daten angibt).

2. ich datenunabhängikeit erhalte, was für mich mittelbar oder in der zukunft wichtig ist. und wie der name zukunft schon sagt, man kennt sie nicht. so kann ich auch sicherstellen, dass unterschiedliche pogramme diese daten nutzen können.

Falls das abzusehen ist, stimme ich dir bedingt zu. Falls alle Programme die in der selben Art benötigen und diese Zugriffsart einfach ist, würde ich das über eine Bibliothek lösen. Damit habe ich die selben Vorteile ohne den Overhead zu haben.

3. ein dbms bei nicht statischen daten schneller ist.

Das ist schlicht und einfach falsch. Es kann schneller sein, ist es manchmal auch, aber genauso oft ist es langsamer. Es wird in jedem Fall langsamer sein als eine perfekt auf die Anwendungen und Daten zugeschnittene Lösung. Die Frage ist nur, ob sich der Aufwand dafür lohnt oder nicht. Meistens tut er es nicht-

4. es eine sehr einfache benutzerverwaltung der daten gibt, so dass nicht jeder alle daten sehen/ändern kann, sondern nur die gewünschten

Ja, ist nur nicht immer gewünscht.

die diskussion über den sinn von datenbanken gab es meiner meinung schon vor jahren, wo man die notwendigkeit erkannt hat und schließlich angefangen hat, dbms zu entwickeln. nartürlich sei jedem eine andere ansicht darüber gegönnt. besonders cräcks, die alles viel besser können, für die es quasi nur ein schnippsen mit den finger bedeutet, das alles umzusetzen, die der meinung sind, die kochen ja alle eh nur mit wasser, bitte sehr. ich für meinen teil würde ein dbms benutzen, solange es sich nicht um private daten handelt.

Datenbanken sind sinnvoll, das bestreitet niemand, nur nicht für jede Anwendung und alle Anforderungen. Du würdest also auch sämtliche Konfigurationsdaten deiner Applikation in Datenbanken ablegen? Manche Daten gehören in Datenbanken, andere nicht, aber nur das eine oder andere einzusetzen, halte ich für viel zu stark vereinfacht.

lass mal die natur aus dem spiel, die ist nämlich auch wie die daten unabhängig. das problem der datei verwaltung der daten ist, dass man anfangs mit den gleichen ansätzen rangegangen ist, wie du nun auch argumentierst. man hatte feste strukturen und dachte, dass läßt sich doch wunderbar abbilden. das war aber sehr kurzsichtig, wie sich später herausgestellt hat. die unternehmen sind nämlich gewachsen oder haben sich verändert und somit haben sich auch die strukturen verändert. und genau das hat zu problemen geführt, dass sich ein unternehmen "der natur den daten" anpasen mussten. und daraus hat man gelernt, dass an eben nicht weiss, dass strukturen immer so bleiben, wie sie sind und genau aus diesem grund gibt es dbms.

Selbst mit Datenbanken hätte nicht einfach nur die Datenstruktur erweitert werden können. Ich habe sowohl mit solchen alten Ansätzen gearbeitet (von Files über hierarchische Datenbanken bis zu RDBMS und objektorientierten Ansätzen) und kann dazu nur eins sagen, egal welcher Ansatz, irgendwann kommt immer der Punkt wo du die Daten migrieren musst.

Oracle hat ein Haufen Begriffe, inklusive dem der Datenbank neu (falsch im Vergleich mit der Datenbanktheorie) definiert. Wenn du von der Oraclespezifischen Definition redest, musst du das sagen, ansonsten geh ich von der Definition aus, wie sie die Datenbanktheorie vorgibt.

ein checkpoint ist auch unter mssql kein abschluss einer transaktion. was du meinst ist ein commit befehl.

Nein, ein Commit-Befehl ist eine mögliche Implementierung eines Checkpoints. Ausserdem gibt es erheblich mehr Datenbanken als Oracle und MSSQL.

so weit ich es weiss arbeiten alle dbms so, dass sie erst die log-dateien schreiben und dann später die daten-dateien ändern. es wäre schwierig anders umzusetzen.

Gerade Oracle tut das nicht in jedem Fall. (Ja, ich habe genug Oracle Kurse gehabt). Die Logdateien werden aber auch auf HDs geschrieben, müssen sie ja auch zumindest ab dem Zeitpunkt, wo eine Transaktion abgeschlossen ist. Siehe dazu Definition einer Transaktion.

im falle eines fehlers muss ein logeintrag vorhanden sein, bevor daten-dateien geändert wurden. dies macht auch einen vorteil des dbms gegenüber dem datei-zugriff deutlich. bevor datenblöcke wieder auf die festplatte geschrieben werden, können mehrere tranasktionn auf die gleichen datensätze ausgeführt wprden sein und trotzdem schreibt er den entgültigen datensatz nur einmal auf die platte und nicht mehrmals.

Ich leugne nicht die Möglichkeiten eines DBMS, auch nicht das es eine gute und nützliche Erfindung ist. Es ist nur nicht immer die ideale Lösung.

Gruss Daniela

[Ilja]

yo,

Stimmt, du schreibst nicht vor, du sagst nur, sie wären in jedem Fall suboptimal.

ganz genau, das ist mein meinung. und warum behaupte ich so etwas, obwohl auch ich die zukunft nicht kennen kann ? eben weil ich sie nicht kenne und keiner das tut. dbms ist ein mittel, daten mit einer größeren unabhängig zu halten, womit man besser für die ungewisse zukunft gewapment ist. und dieses argument ist für heutige betriebe, die sich ständig verändern, lebensnotwendig.

Ja, in vielen, aber nicht in allen, inklusive in dem Fall nicht (solange er nicht eine spezielle Nutzung der Daten angibt).

schau, du redest von speziellen fällen, die alle eintreten müssen, damit eine direkte datei-verwaltung sinn macht. wenn er aber keine speziellen angaben macht, warum konstruierst du dann welche, wo sind seine angaben, dass es sich um genau diese speziallfälle handelt ?

vielleicht solltest du mal anders an die sache herangehen. wir haben nun beide gesehen, dass es viele wenns und abers gibt, eine direkte datei-verwaltung zu implementieren, dass ich dadurch sehr eingeschränkt bin, wenn nicht sofort, dann auf die gefahr hin auf eine ungewisse zukunft. wenn es schon auf der einen seite so viele möglichen gefahren gibt, warum sollte ich mich dann nicht für ein dbms entscheiden, was spricht dagegen ? ich sehe nur negative seiten der direkten datei-verwaltung, zum beispiel dass ich mich von mitarbeitern abhängig mache, die das programmiren müssen. auf der anderen seite bin ich mit dbms immer auf der guten seite, ausserdem kennen viele diese programme, ich bin somit auch von den angestellten unabhägiger. was also spricht gegen ein dbms ?

Falls das abzusehen ist, stimme ich dir bedingt zu.

das reicht aber nicht, ich möchte auch das unvorhersehbare mit einbeziehen. und das geht nur über ein dbms. unvorhrsehbar ist laut definitiv eben nicht abzusehen.

Das ist schlicht und einfach falsch. Es kann schneller sein, ist es manchmal auch, aber genauso oft ist es langsamer. Es wird in jedem Fall langsamer sein als eine perfekt auf die Anwendungen und Daten zugeschnittene Lösung. Die Frage ist nur, ob sich der Aufwand dafür lohnt oder nicht. Meistens tut er es nicht-

also wenn es schneller sein kann, da kann es ja nur zum teil falsch sein. und wenn ich davon ausgehe, dass sich meine datenstrukturen auch mal ändern, dan gibt es nicht die eine perfekte lösung. und selbst wenn ich einen timesnap mache, dann muss gelten, dass:

1. die datenstruktur gleich bleibt.
2. die anzahl der datensätze gleicht bleibt
3. der inhalt der daten gleich bleibt
4. die Anforderung der daten immmer gleich ist

um eine optimale lösung zu erstellen. und diese vier bedingungen treten so selten ein, dass jemand schon expliziet darauf hinweisen muss, dass genau diese bedingungen gelten. und dann würde ich mir diese aussage auch so unterschreiben lassen. und nun frage ich dich, hat hier irgend jemand diese bedingungen genannt ? ist es nicht besser davon auszugehen, dass diese bedingungen nicht gelten, wenn sie keiner erwähnt, anstelle sie zu unterstellen ?

Datenbanken sind sinnvoll, das bestreitet niemand, nur nicht für jede Anwendung und alle Anforderungen.

ja, nur wenn diese 4 punkte dort oben gegeben sind. nur ist das hier nicht der fall.

Nein, ein Commit-Befehl ist eine mögliche Implementierung eines Checkpoints. Ausserdem gibt es erheblich mehr Datenbanken als Oracle und MSSQL.

haarspalterei, dann zeige mir ein dbms, dass checkpoints als commits einsetzt. nun sind oracle und mssql ja nicht gerade kleine rand dbms. und das hat auch wenig mit der ursprünglichen diskussion zu tun.

Gerade Oracle tut das nicht in jedem Fall. (Ja, ich habe genug Oracle Kurse gehabt). Die Logdateien werden aber auch auf HDs geschrieben, müssen sie ja auch zumindest ab dem Zeitpunkt, wo eine Transaktion abgeschlossen ist. Siehe dazu Definition einer Transaktion.

erstens geht das auf kosten der sicherheit, wenn keine logdateien geschrieben werden. man nimmt das risiko unter umständen bewußt in kauf, zum beispiel weil ein datenimport bevorsteht und man danach sowieso ein backup fährt. und ja, logdaten werden mit einem commit in die logdatien festgeschrieben. dies ist ein notweniger prozess, um daten in die datendateien festschreiben zu können. man kann das beides nicht vergleichen, weil das eine eine vorarbeit ist, die man leisten muss, um die datenintegrität sicherzustellen. es geht meiner meinung nach nicht ohne.

Ilja

[Jörg Lorenz]

Halli hallo,

die Diskussion ist für mich sehr interessant und ich versuche, allen Betrachtungsweisen etwas abzugewinnen.

Eigentlich halte ich in diesem Forum raus, aber nun muß ich doch mal meinen Senf dazu geben:

Weist du was das Problem ist? Du schreibst allen Anwendungen vor, die Fähigkeiten eines DBMS zu benötigen. Das ist aber nicht so. Ob ein volles DBMS benötigt wird, sagen nur die Daten und die Anwendung aus. Wenn nur minimalste Teile eines DBMS benötigt werden weil die Anwendung einfach nicht mehr braucht und auch nicht mehr brauchen wird, dann ist es manchmal auch sinnvoller, nur diese kleinsten Teile zu schreiben die man braucht.

Das sehe ich genauso. Ich habe zwar von PHP & Co. keine Ahnung, schreibe aber Anwendungen in VB, VBA, usw. Und da ist immer die Frage, woher die Daten stammen und wie sie verwaltet werden, sprich, die Vorgabe.

Zur Zeit arbeite ich an einem Programm in VB, in der verschiedenste Datenquellen vorgegeben sind: Preislisten in Excel-Dateien, Adreßbuch in Komma-getrennten Textdateien, andere Daten in von mir definierten Formaten. DBMS? Geht nicht.

In einem anderen Fall hatte ich die Aufgabe, eine Oberfläche zur Verwaltung von zwei riesigen (eine Datei ca. 23 MB groß) dBase-Dateien in VBA zu schreiben. SQL oder ADO wären sinnvoll gewesen, aber eine Abfrage dauerte ... Was habe ich gemacht? Ich habe die Dateien per VBA in Excel (!) öffnen lassen und mit dessen Bordmitteln per VBA bearbeitet. Das ging dann wesentlich schneller und der Kunde war zufrieden.

Was ich damit sagen möchte: Man sollte schon unterscheiden, was man wo anwendet und nicht verallgemeinern. Hauptsache, es funktioniert.

Viele Grüße

Jörg

[Tom]

Hello,

Hallo Ilja,

zuerst mal: es heisst der Index und die Indizes ;-)

oder auch die Indexe. Schau mal in den Duden ;-))

Liebe Grüße aus http://www.braunschweig.de

Tom

[Andreas Korthaus]

Hallo!

Bedenke dass viele Datenbanken ihre Daten ebenfalls in Flat-Files speichern. Den Algorithmus den die Datenbank verwendet kannst Du natürlich auch in Deinem Programm selbst implementieren. Der Vorteil der Datenbank ist halt, dass Du den effizienten Algorithmus verwenden kannst, und das ganze noch über ein sehr einfaches Interface.
Wenn Du Dich gut auskennst und viel Zeit hast wirst Du es in den meisten Fällen wohl mit einer eigenen Implementierung schneller hinbekommen als über eine Datenbank - wie CK schon mehrfach sagte.
Stell Dir vor Du implementierst das ganze 1:1 so wie die Datenbank selber, nur eben direkt - ohne den Overhead von SQL, TCP/IP... und ohne alles was Du nicht brauchst. Im Prinzip braust Du eine hoch spezialisierte Datenbank in Dein Programm direkt ein.

Grüße
Andreas

[Tom]

Hello,

Hallo!

Bedenke dass viele Datenbanken ihre Daten ebenfalls in Flat-Files speichern.

Na, wo denn sonst? Auf Memory-Stick?

Den Algorithmus den die Datenbank verwendet kannst Du natürlich auch in Deinem Programm selbst implementieren. Der Vorteil der Datenbank ist halt, dass Du den effizienten Algorithmus verwenden kannst, und das ganze noch über ein sehr einfaches Interface.

Wenn Du Dich gut auskennst und viel Zeit hast wirst Du es in den meisten Fällen wohl mit einer eigenen Implementierung schneller hinbekommen als über eine Datenbank - wie CK schon mehrfach sagte.

Eine DB kann man in PHP nicht nachbilden. Dann bleibt das System stehen. PHP unterstützt nur mäßig (pack() und unpack() ) Linearisierte Datenstrukturen.

Stell Dir vor Du implementierst das ganze 1:1 so wie die Datenbank selber, nur eben direkt - ohne den Overhead von SQL, TCP/IP... und ohne alles was Du nicht brauchst. Im Prinzip braust Du eine hoch spezialisierte Datenbank in Dein Programm direkt ein.

Er will doch nur einen Log-Datensatz hinten anhängen. Von mehr war nicht die Rede.

Und hast Du schon einemal die Performance einer MySQL-DB bei Delete-Operationen gemessen? Grottenschlecht das ganze. Auf Delete ist MySQL nicht ausgelegt. Da war dBase besser mit dem Befehl Pack.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Christian Kruse]

Hallo Tom,

Bedenke dass viele Datenbanken ihre Daten ebenfalls in
Flat-Files speichern.

Na, wo denn sonst? Auf Memory-Stick?

Was hat das Medium mit der Datenstruktur zu tun?

Grüße,
 CK

[Tom]

Hello,

Hallo Tom,

Bedenke dass viele Datenbanken ihre Daten ebenfalls in
Flat-Files speichern.

Na, wo denn sonst? Auf Memory-Stick?

Was hat das Medium mit der Datenstruktur zu tun?

Ok, ertappt, da hast Du recht.
Dann müssten wir also erstmal definieren, was ein Flat-File ist. "Flat-Files" waren für mich bisher alle Dateien, die ich über fopen89, fread(), fwrite() oder entsprechende Methoden ansprechen durfte.

Da gibt es natürlich viele verschiedene Konstruktionen:

• lineare Dateien
• direkt gestreutet Dateien
• wahlfreie Satzlänge (Textdateien)
• feste Satzlänge mit varianter Feldstruktur
• feste Satzlänge, feste Feldlänge
• logisch seitenorientierte Dateien
• physisch seitenorientierte Dateien
    (an die Hardware gekoppelte Seitengrößen)
• welche mit Datei-Locking
• welche mit Page-Locking
• welche mit Record-Locking
  ...

In welchem Typ speichert eine DB nun ihre Daten?

Liebe Grüße aus http://www.braunschweig.de

Tom

[Christian Kruse]

Hallo Tom,

Dann müssten wir also erstmal definieren, was ein Flat-File ist.
"Flat-Files" waren für mich bisher alle Dateien, die ich über
fopen89, fread(), fwrite() oder entsprechende Methoden ansprechen
durfte.

Die sind nur Abstraktionen der System-Funktionen mit eingebauten
Caching. Letztenendes benutzt man die gleichen Funktionen für *jede*
Art Datei.

In welchem Typ speichert eine DB nun ihre Daten?

Das ist absolut abhängig von DBMS?

Grüße,
 CK

[Ilja]

yo,

Den Algorithmus den die Datenbank verwendet kannst Du natürlich auch in Deinem Programm selbst implementieren.

es macht aber keinen sinn, einen bstimmten algorithmus zu benutzen. da die effektivität unter anderem von dr anzahl und der art der datensätze abhängt. demzufolge sind im laufe der zeit unterschiedliche methoden notwenig, um eine optimale performance zu erreichen. ich kann nicht einfach algorithmus B immer anwenden.

Der Vorteil der Datenbank ist halt, dass Du den effizienten Algorithmus verwenden kannst, und das ganze noch über ein sehr einfaches Interface.

das ist einer der vorteile, aber damit hört es nicht auf.

Wenn Du Dich gut auskennst und viel Zeit hast wirst Du es in den meisten Fällen wohl mit einer eigenen Implementierung schneller hinbekommen als über eine Datenbank - wie CK schon mehrfach sagte.

da hab ich meine zweifel. erstens müsste ich mechansm implemeniteren, die auch in einer dbms beutzt werden. und dann hätte ich ja quasi auf eine datenbank zugeschnittenes dbms, was christian ja aussagen will. ABER ich komme sofort in schwulitäten, wenn ich zwa das gleiche programm, aber mehrere benutzer habe, die auf die datendateien zugreifen. damit muss ich zum beispiel sofort alle änderungen der daten auf die platte schreiben und zwar immer. programm A weiss nämlich ncht, was programm B mit den daten bemacht hat und deswegen muss ich auf die platte schauen. und das hat grosse nachteile. es stimmt also ncht zu sagen, dbms sind nur eine verallgemeinerte form der datenhaltung.

ein dmbs ist ja auch nur ein programm. aber jetzt kommt die wichtige aussage. dadurch dass ich nur EIN programm benutzte über das alle anderen auf die daten zugreifen, stehen mir andere mechanism zur verfügung als bei der verwendeung mehrerer programme.

und wenn jetzt jemand fragt was schneller ist, dann kann man natürlich sagen, du musst einfach mal eine quasi dbms entwicklen, was auf deine daten zugschnitten ist und weiterhin auch nur von einer person/programm gleichzeitig benutzt werden darf. aber das ist doch murks, jemanden das zu empfehlen.

Ilja

[Tom]

Hello,

[...]entscheiden, wie ich suche. Ob binär, ob per Hash-Index, das bleibt
völlig mir überlassen.

Sei bitte so lieb und beseitige für mich ein für alle Mal die Verständnisschwierigkeit: Was ist ein Hash-Index oder auch Hash-Algorithmus? Ich kanns mir einfach nicht merken.

such mal aus 1 millionen datensätze einen bestimmten eintrag ohne
einen solchen indize zu besitzen. eine blosse dateispeicherung wird
das nämlich nicht tun.

Bei direkt gestreuten Dateien habe ich den im ersten Zugriff. Dann nennt man es allerdings auch "holen" und wenn ich doch suchen muss, sollte ich schon wissen, welche Sortierung vorliegt. Außerdem sind Dateisysteme heute so schnell, wenn sie genügend Speicher haben, dass man den Datensatz auch bei unsortierten Daten schnell finden kann. Man liest immer Blöcke ein gemäß der Speicherzuteilung und reloziiert die, das heißt, man schaut, wo in den gelesenen Daten der erste Satz anfängt und wo der letzte aufhört und schneidet sich so eine passende Datenmenge aus dem Block raus. Der nächste Block wird dann entsprechend verschoben begonnen. Der Sinn dahinter ist die Abarbeitungsgeschwindigkeit im Speicher, die heute ca. 2600 mal so hoch ist, wie die Accelleration auf die Platten. Bitte nicht verwechseln mit dem Datendurchsatz, wenn man die passende Stelle erst einmal gefunden hat. Der ist mit ca. 20-100MByte/s durchaus beachtlich.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Christian Kruse]

Hallo Tom,

[...]entscheiden, wie ich suche. Ob binär, ob per Hash-Index,
das bleibt völlig mir überlassen.

Sei bitte so lieb und beseitige für mich ein für alle Mal die
Verständnisschwierigkeit: Was ist ein Hash-Index oder auch
Hash-Algorithmus? Ich kanns mir einfach nicht merken.

Mit Hashing wird eine Methode zum berechnen einer Prüfsumme
bezeichnet. Es wird in diesem Fall aus einem Eingabe-Wert eine
möglichst eindeutige Zahl erstellt. Diese Zahl wird dann benutzt,
um Werte in einer Tabelle abzuspeichern. Der Aufwand, diese Zahl
zu generieren, ist im Allgemeinen um ein vielfaches kleiner als
eine Suchmethode, da einfach viel, viel weniger Daten bearbeitet
werden müssen: habe ich eine Datenmenge von 10k Daten, so müssen bei
binären Such-Algorithmen immer noch max. 14 Vergleiche gemacht
werden und Einfüge-Operationen sind sehr aufwendig. Bei
Hashing-Algorithmen dagegen ist der Aufwand (linear) abhängig von der
Länge des Daten-Schlüssels. Benutzt man Schlüssel von 5 Zeichen, so
müssen 5 Operationen gemacht werden, um das Datum aus der Tabelle
zu holen oder es in die Tabelle hineinzustecken -- (theoretisch)
unabhängig von der Datenmenge. Die Grenze dieses Systems ist ein
Problem der Eindeutigkeit: bei einer unbegrenzten Eingabemenge
haben wir einen begrenzten Abbildungsraum, deshalb können mehrere
Schlüssel denselben Index ergeben. Trotz allem ist diese
Zugriffs-Methode für Key-Value-Datenformate im Mittel ein ganzes
Stück schneller als "herkömmliche" Such- und Sortier-Algorithmen.

Grüße,
 CK

[Tom]

Hello Christian,

vielen Dank für die Beschreibeung.

Wahrscheinlich wird es aber erst wirklich klick machen, wenn ich es selber einmal nachempfunden habe, so ein Ding aufzubauen und zu evaluieren.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Tom]

Hello,

Log-Datei öffnen
Datensatz eintragen
Log-Datei schliessen

oder:

MySQL Connect herstellen
Datensatz eintragen

Selbst wenn die DB-Connection bereits besteht, wird die LowLevel-Append-Variante um einiges schneller sein. Ich glaube auch nicht, dass PHP hier viel Overhead in die Dateifunktionen eingebaut hat. Es müsste sich also mit zwei Accellerertionszyklen (ca. 8ms) abhandeln lassen. Und wenn ein RAID hinter dem Dateisystem steckt, geht auch noch viel schneller.

Die Datenbank hat im Prinzip die gleichen Probleme der Accelleration (Der Actuator der HDD muss gezielt positioniert werden).

Wenn Du nicht den Fehler machst, bei mehereren Logeinträgen jeden einzeln  mit einem fwrite() wegzuschreiben, sondern den ganzen Buffer auf einmal wegschreibst (also auch mehrere "Zeilen" als gemeinsamen Stream) dann bist Du mit der LowLevel-Lösung schneller.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Christian Kruse]

Hallo Tom,

Selbst wenn die DB-Connection bereits besteht, wird die
LowLevel-Append-Variante um einiges schneller sein. Ich glaube
auch nicht, dass PHP hier viel Overhead in die Dateifunktionen
eingebaut hat. Es müsste sich also mit zwei Accellerertionszyklen
(ca. 8ms) abhandeln lassen. Und wenn ein RAID hinter dem
Dateisystem steckt, geht auch noch viel schneller.

Die Datenbank hat im Prinzip die gleichen Probleme der
Accelleration (Der Actuator der HDD muss gezielt positioniert
werden).

Ich weiss nicht, wovon du redest. Würdest du das bitte näher
ausführen? Auch die Fachbegriffe, bitte. Danke.

Wenn Du nicht den Fehler machst, bei mehereren Logeinträgen jeden
einzeln  mit einem fwrite() wegzuschreiben, sondern den ganzen
Buffer auf einmal wegschreibst (also auch mehrere "Zeilen" als
gemeinsamen Stream) dann bist Du mit der LowLevel-Lösung schneller.

PHP cached. Es macht keinen Unterschied, ob du fünf mal fwrite()
aufrufst oder nur einmal. Der Systemcall wird genau so oft gemacht.

Grüße,
 CK