Lokale Archivierung, chronologisch geordnet. Welches DBMS brauche ich?

[mkinzler]

Zitat:

Ich meinte nur: Wenn auf meinem System kein autark laufender Server installiert ist. Sondern sowohl Client- als auch Server-Funktionalität direkt als dll im Anwendungsverzeichnis vorliegen. Muss ich mich dann auch vor irgendeinem "Housekeeping" im Hintergrund hüten?

Dann kann man davon Ausgehen, dass der Server in der Dll ( im Falle von FB embedded) das "housekeeping" erledigt, wenn er vom Hauptprogramm entladen wird; über SQlite kann ich wenig sagen.
Aber was spricht dagegen, trotzdem anstatt der Kopie der Datei die Bordmittel zum geordneten Backkup zu verwenden ( Housekeeping++)?

Zitat:

Ist "SQL-Statement" jetzt ein ganz spezieller Begriff?

Darunter versteht man eine Abfrage ( DDL DML).

[Der schöne Günther]

Zitat von mkinzler:

Darunter versteht man eine Abfrage ( DDL DML).

Also dann wohl doch nur die Frage, ob ich überhaupt eine grobe Vorstellung von dem habe, was ich tue. Ich glaube ja


Und schon sind wir auf der vierten Seite. Dann vielen Dank, ich denke, meine Entscheidung dann auch gefällt zu haben.

An DB-Funktionalität brauche ich nur

1. Benutzer/Rechte-Einstellungen, Parameterbelegungen für externe Dinge ... Einstellungen halt. Wenige Kilobyte.
2. Ein Langzeit-Datengrab, "Append"-Modus. Nach kurzem Durchrechnen sollte das ein halbes Dutzend GB pro Jahr nicht überschreiten. Single-User-Betrieb.

Für 1) setze ich seit Wochen (Monaten?) SQLite ein und bin höchst zufrieden.

Für Punkt 2) glaube ich nun, mit der Advantage Local DB auf dem richtigen Pfad zu sein. Die wird im aktuellen Projekt auch schon seit vielen Jahren genau dafür benutzt. Ich freue mich über dank des ISAM-Zugriffs über eine sehr hohe Performance, die unkomplizierte Einbindung und Deployment und für XE4 verfügbaren Delphi-Komponenten.

Ich glaube, davon kann mich nun keiner mehr abbringen

[stahli]

... will sicher auch keiner
Im Grunde kannst Du für die Anforderung wohl irgendeine Datenbank benutzen (mit der Du halt gut klar kommst).

Ich hatte wegen SQL gefragt, weil Du von Lücken oder falschen Reihenfolgen (oder so) bei gelöschten Datensätzen geschrieben hattest.
Bei SQL-Abfragen ist das ja aber eigentlich unerheblich, da die Reihenfolge und Filterung ja von der Abfrage bestimmt wird (anders als wenn Du eine TTable an eine Datenbanktabelle hängen würdest - wie vielleicht früher mit der BDE).

[Der schöne Günther]

Richtig. Das war mir auch klar. So kannte ich es auch nur bei ganz hausüblichen relationalen DMBS. Aber ich fand für meinen "speziellen" Zweck muss das doch besser gehen. Und die ADS macht das genau so.

[Perlsau]

Zitat von hstreicher:

Zitat von Perlsau:

Zum Punkt Backup:

Autsch, das würde ich mir sofort abgewöhnen, Firebird (wahrscheinliche alle Transactionsorientierten DB's) führt nach dem Disconnect noch einiges an Housekeeping durch (Garbage collection, sweep u.s.w) da kann man sich mit einem Filecopy eine Datenbank kopiern die zwischen 2 Zuständen hängt und unbrauchbar ist , besonders die erste DB Page , also vorne in der Datei dürfte mit Ihren Pointern, Transactioncountern wohl erst am Schluss upgedated werden.
Immer schön gbak oder die Sicherung über die API oder Komponenten ausführen.

Davon habe ich in all den den Jahren, in denen ich Firebird einsetze, absolut nichts bemerkt. Ebenso war das Änderungsdatum bislang immer genau das Datum des letzten Programmendes bzw. des Disconnect in IbExpert. Beim direkten Arbeiten an der Datenbank mit IbExpert lege ich zuvor immer eine Kopie der aktuellen DB an, bevor ich loslege. Wenn mal was schiefging (was gelegentlich vorkommt, besonders bei verschachtelten SQL-Befehlen) kopierte ich die zuvor angelegte Kopie wieder in den Datenbank-Ordner und konnte damit ausnahmslos ohne Probleme weiterarbeiten: Kein Datenverlust, kein Fehlverhalten, keine Fehlermeldungen etc.

Dürfte ich erfahren, woher du die Information hast, daß die Firebird-Server-Software auch nach dem Disconnect noch irgendwelche Aktionen an der soeben verwendeten Datenbank durchführen soll?

[Perlsau]

Zitat von Der schöne Günther:

Zitat von stahli:

Kannst Du das nochmal anders fragen?

Ich meinte nur: Wenn auf meinem System kein autark laufender Server installiert ist. Sondern sowohl Client- als auch Server-Funktionalität direkt als dll im Anwendungsverzeichnis vorliegen. Muss ich mich dann auch vor irgendeinem "Housekeeping" im Hintergrund hüten?

Wie ich eben im Firebird-Buch gelesen habe, kann ein laufender Embedded-Server nur durch das Beenden der Anwendung beendet werden. Und wenn der Server nicht mehr läuft, kann er auch nichts anrichten.

[taveuni]

Zitat von Der schöne Günther:

[..] Aber ich fand für meinen "speziellen" Zweck muss das doch besser gehen. Und die ADS macht das genau so.[..]

Ich habe nicht alles durchgelesen. Aber mit so einer Aussage (bzw. die Umsetzung basierend auf dieser) schiesst Du Dir selbst ins Knie. Datenhaltung sollte immer möglichst unabhängig vom DBMS sein. Sich jetzt auf ein "spezielles" zu konzentrieren und vor allem Deine Applikation darauf zu entwickeln ist böse. Du kannst alles mit einer freien "normalen" Datenbank erledigen. Hast dann auch die Möglichkeit von einer Embedded in einer Minute auf einen Server zu wechseln usw.

[tsteinmaurer]

Zitat:

Dürfte ich erfahren, woher du die Information hast, daß die Firebird-Server-Software auch nach dem Disconnect noch irgendwelche Aktionen an der soeben verwendeten Datenbank durchführen soll?

Das kann schon passieren, dass der Firebird Prozess die Datenbankdatei noch in der Mangel hat, obwohl sich z.b. der letzte User disconnected hat. Ein gutes Beispiel ist die Sweep-Aktivität. Ein guter Check, ob die Datenbank noch in Verwendung ist, ist diese versuchen im Dateisystem umzubenennen. Wenn das klappt, dann ist keiner mehr drauf.

Wenn man während des Betriebs eine konsistente Kopie auf Dateisystemebene ziehen möchte, dann kann man nbackup verwenden. Leider hat nbackup unter Hochlast und Firebird 2.1 immer wieder Probleme verursacht. In 2.5.x habens das im Griff.

gbak ist natürlich IMMER eine Möglichkeit. Für Datenbanken im dreistelligen GB Bereich halt mühsam, sprich zeitintensiv.

[Der schöne Günther]

Zitat von taveuni:

Zitat von Der schöne Günther:

[..] Aber ich fand für meinen "speziellen" Zweck muss das doch besser gehen. Und die ADS macht das genau so.[..]

Ich habe nicht alles durchgelesen. Aber mit so einer Aussage (bzw. die Umsetzung basierend auf dieser) schiesst Du Dir selbst ins Knie. Datenhaltung sollte immer möglichst unabhängig vom DBMS sein. Sich jetzt auf ein "spezielles" zu konzentrieren und vor allem Deine Applikation darauf zu entwickeln ist böse. Du kannst alles mit einer freien "normalen" Datenbank erledigen. Hast dann auch die Möglichkeit von einer Embedded in einer Minute auf einen Server zu wechseln usw.

Die Advantage ist von der Ansprache genauso SQL-92 (oder irgendein anderes SQL-xx) konform wie alle anderen auch. Im Hintergrund sucht und verwaltet sowieso jede anders, das sehe ich nicht, soll ich nicht sehen, und kann ich nicht sehen. Eine Super-Speziellösung ist die Advantage nicht. Sie macht arbeitet nur im Hintergrund die Arbeit etwas anders als bsp. eine Postgres-DB.

[p80286]

Zitat von Der schöne Günther:

Sie macht arbeitet nur im Hintergrund die Arbeit etwas anders als bsp. eine Postgres-DB.

Nichts für ungut, aber da habe ich so meine Zweifel. Alle DB-Hersteller arbeiten mit mehr oder weniger der gleichen Technologie, die für den einen oder anderen Anwendungsfall optimiert wurde. Aber was ich da auf der ADS-Seite gelesen habe klang so als wäre ISAM ein echtes Qualitätsmerkmal und keine Selbstverständlichkeit.

Gruß
K-H