Firebird Datenbankgröße

[Lemmy]

@Thomas: ich habe das ehrlich gesagt noch nie gemacht - aber wo ist der Unterschied zwischen einer (eingestellten) Read-Only DB und einer DB in die ich keine Inserts mache? Sortiert FB hier dennoch immer wieder Daten um?

[mkinzler]

Er macht ja Inserts

[Dejan Vu]

Und die sind immer am Ende? So von wegen Timestamp und Index drauf. Weiß jetzt nicht, wie FB das macht, aber die Daten werden ja wohl ans Ende gepackt,

[mkinzler]

Nein. Wenn vorher ein datensatz gelöscht wurde, wird der Speicherplatz für neue Inserts wieder verwendet.

[Dejan Vu]

Zitat von mkinzler:

Nein. Wenn vorher ein datensatz gelöscht wurde, wird der Speicherplatz für neue Inserts wieder verwendet.

Werden hier Datensätze gelöscht? Soweit wie ich das bisher verfolgt habe: Nein. Und dann stimmt meine Annahme ja wohl, das die neuen Datensätze automatisch und immer ans Ende kommen. Und wenn das so ist, kann man die Seiten auch mit einem Fillfactor von 100% füllen, oder nicht?

[p80286]

Zitat von Lemmy:

@Thomas: ich habe das ehrlich gesagt noch nie gemacht - aber wo ist der Unterschied zwischen einer (eingestellten) Read-Only DB und einer DB in die ich keine Inserts mache? Sortiert FB hier dennoch immer wieder Daten um?

Du hast Die Updates übersehen! Je nach indizierten Feldern, kannst Du einige Änderungen in den Indizies bekommen, auch wenn der RecordCount stabil bleibt. Eine Readonly-DB ist eigentlich tot.

Gruß
K-H

[Lemmy]

Zitat von p80286:

Zitat von Lemmy:

@Thomas: ich habe das ehrlich gesagt noch nie gemacht - aber wo ist der Unterschied zwischen einer (eingestellten) Read-Only DB und einer DB in die ich keine Inserts mache? Sortiert FB hier dennoch immer wieder Daten um?

Du hast Die Updates übersehen! Je nach indizierten Feldern, kannst Du einige Änderungen in den Indizies bekommen, auch wenn der RecordCount stabil bleibt. Eine Readonly-DB ist eigentlich tot.

Gruß
K-H

Übersehen nicht, nur nicht explizit drauf eingegangen. Aufgrund der Beschreibung bin ich davon ausgegangen, dass die Daten einmal importiert werden um dann für Auswertungen vorgehalten werden bzw. bei Aktualisierungen die Daten als "Masseninserts" rein kommen und nicht individuell von den Anwendern geändert werden können / sollen. Und hier würde ich (wenn die DB-Größe wirklich ein Thema sein sollte) ggf. die beschrieben Dinge anwenden.

Unter 2.5 soll es ja auch möglich sein über StoredProcedures auf anderen DBs zugreifen zu können. Somit könnten diese Gerätedaten in eigene, ggf. auch als Read-OnlyDBs ausgelagert werden und die Pages voll gemacht werden.

Aber hier müsste der Threadstarter vielleicht noch Licht ins Dunkel bringen...