Speicherbedarf bei Datenbank Query

[mse1]

Zitat:

Zitat von AndyDF (Beitrag 1270685)

Ich möchte hier nicht über Sinn oder Unsinn diskutieren, ob 30T sinnvoll sind oder nicht. ;)

Mit MSEgui sind übrigens queries mit einigen 100'000 records absolut machbar.

Zitat:

Zitat von Sir Rufo (Beitrag 1270690)

Liegen die Daten jetzt aber speicheroptimiert vor (die Felder nur so lang wie nötig), dann muss für jede Zeile die aktuelle Zeilenlänge bestimmt werden. Vereinfachen kann man das durch eine Längenangabe vor jeder Zeile, die dann aufaddiert wird. Es bleibt aber dabei, dass der Verwaltungsaufwand steigt und damit die Performance sinkt.

Wenn Änderungen an den Daten erfolgen, dann wird das insgesamt dramatischer, denn einfach so kann man eben nicht etwas im Speicher "dazwischen einfügen". Hier müssen dann ganze Blöcke verschoben werden. Ist der Platz aber schon reserviert, dann kann der einfach dort hineingeschrieben werden.

Wie gesagt, auch in MSEgui ist der Rekordpuffer Aufbau fix. Für Textdaten wird UnicodeString verwendet welcher im Recordpuffer den konstanten Speicherbedarf eines pointers hat.

[Dejan Vu]

Zitat:

Zitat von mse1 (Beitrag 1270702)

Mit MSEgui sind übrigens queries mit einigen 100'000 records absolut machbar.

Klar, wenn bei einem VarChar(1000) nur ein Zeichen belegt ist...:lol: Aber im Ernst: Das ist schon optimal so und imho auch keine Performancebremse, wenn man den Speicher individuell reserviert. Der Speichermanager ist dafür zuständig, das halbwegs schnell hinzubekommen. Und bei gerade mal -von mir aus- 500.000 einzelne Zellen ist das eh in ein paar ms gemacht. Der bottleneck ist sowieso die Query selbst bzw. die Übertragung.

[mse1]

Mit SQLite ergeben sich für 1'000'000 records 3..4 Sekunden Ladezeit auf einem alten AMD Athlon Linux-Rechner.

[Dejan Vu]

Lokal. Wie interessant. ;-)

[mse1]

Für Firebird über ein 100MHz Netzwerk werden es dann 7..8 Sekunden für die gleichen Daten.