Lokale Archivierung, chronologisch geordnet. Welches DBMS brauche ich?

[p80286]

Zitat von Der schöne Günther:

Ich möchte nutzen, dass eigentlich schon vorher relativ sicher ist, wo in der DB ich meine Datensätze finde. Oder geben das relationale DBMSs einfach nicht her?

Vereinfacht gesagt, liegen die Daten in einer Datenbank in einem ungeordneten Haufen herum. Durch die Nutzung verschiedener Indizes bekommst Du "Struktur" in dieses Chaos, und je nach verwendetem Index eine andere.
Du mußt/kannst also nicht wissen wo die Daten liegen.

Meiner Meinung nach geht kein Weg an Sequenes/AutoID vorbei, da alle natürlichen Schlüssel an Datenfehlern kranken können.

Ob die zeitliche Abfolge über einen Timestamp oder DateTime abgebildet wird, hängt von der DB ab, die Auflösung muß hoch genug sein.

Gruß
K-H

[stahli]

Eine einfache Lösung ist Firebird embedded (kostenfrei).

Dann braucht der Anwender keinen Server installieren sondern nur ein paar dll´s bei der Exe. Die fdb-Datei enthält alle Daten und kann einfach gesichert, kopiert oder verschoben werden.

Der Zugriff kann über FireDAC erfolgen (das habe ich sogar hin bekommen ).

Grundsätzlich sind Abfragen in einer relationalen Datenbank unsortiert, sofern man nicht einer bestimmte Sortierung vorgibt.
Das könnte über ein TimeStamp- oder AutoInc-Feld erfolgen. Da unterscheiden sich die Datenbanken ziemlich.

Im Firebird kann man einen "Generator" in Verbindung mit "Triggern" definieren. Der Generator wird dann z.B. für jeden neuen Datensatz in der Tabelle hochgezählt und der Wert einem gewünschten Feld (z.B. "Id") zugewiesen.

Als Admin-Tool kann ich IBExpert empfehlen. Das ist ziemlich selbsterklärend. Für die 3 Emba-Tools aus dem Ultimate-Paket würde ich das nicht unterschreiben. Wobei dort ein Vergleichstool existiert, das Unterschiede zwischen verschiedenen Datenbeständen finden und zusammenführen kann. Das sah zumindest nicht unteressant aus - wenn man es denn brauchen kann.

[Der schöne Günther]

Je weiter ich stöbere, desto mehr gefällt mir allerdings die Advantage DB: Wer brennend Interesse hat, kann hier den kurzen Artikel ADS Is High Performance lesen.

ADS tut mit seiner "Natural Order" anscheinend genau das, was ich möchte: Die Reihenfolge der Zeilen strikt beizubehalten. Habe ich den ersten Datensatz gefunden der in den Zeitrahmen fällt, kann ich von diesem Punkt aus blitzschnell weiternavigieren.
Bis ich einen Punkt gefunden habe, dessen Zeitstempel nicht mehr ins Zeitfenster passt. Dann kann ich mir schon sicher zu sein, alle zu haben, ohne mir die gesamte Tabelle überhaupt angesehen zu haben.

Zitat:

In the set-based database model, in theory at least, there is no record order. As a result, the SQL language does not support the concept of navigating a database. While some set-based SQL databases know that record B follows record A, the only way to move to a record that is 100 records after record A is to retrieve the record that follows A, then retrieve the record that follows that one, and again, and again, until this task is performed 100 times.

(...)

By comparison, records in an ISAM database have a record order, based on the current index (or natural record order, if no index is currently selected). If you point a Delphi DBGrid to an Advantage table with a million records, and press Ctrl-End, you will move immediately to the last record. This is because Advantage can use the current index or the table's natural order to go to the last record, and then return only those last records needed to fill the display of the DBGrid.

[joachimd]

Zitat von Der schöne Günther:

ADS tut mit seiner "Natural Order" anscheinend genau das, was ich möchte: Die Reihenfolge der Zeilen strikt beizubehalten. Habe ich den ersten Datensatz gefunden der in den Zeitrahmen fällt, kann ich von diesem Punkt aus blitzschnell weiternavigieren.
Bis ich einen Punkt gefunden habe, dessen Zeitstempel nicht mehr ins Zeitfenster passt. Dann kann ich mir schon sicher zu sein, alle zu haben, ohne mir die gesamte Tabelle überhaupt angesehen zu haben.

Diese Aussage ist nicht zu 100% richtig: im ADT Format werden Lücken bei einem INSERT wieder aufgefüllt und damit gibt es keine Natural Order mehr, welche mit der Einfüge-Ordnung übereinstimmt. Das ist nur bei DBF - da bleiben die Lücken bis zum Packen bestehen, selbst nach dem PACK hat man noch dieselbe Ordnung. Ach - und eine ROWID als Primärschlüssel zu nehmen ist mehr als böse.

[Olli73]

Zitat von Der schöne Günther:

ADS tut mit seiner "Natural Order" anscheinend genau das, was ich möchte: Die Reihenfolge der Zeilen strikt beizubehalten. Habe ich den ersten Datensatz gefunden der in den Zeitrahmen fällt, kann ich von diesem Punkt aus blitzschnell weiternavigieren.
Bis ich einen Punkt gefunden habe, dessen Zeitstempel nicht mehr ins Zeitfenster passt. Dann kann ich mir schon sicher zu sein, alle zu haben, ohne mir die gesamte Tabelle überhaupt angesehen zu haben.

Im Normalfall geht man aber nicht die ganze Tabelle manuell selber durch, sondern macht eine SQL-Abfrage:

Code:

select * from TABELLE where MYTIMESTAMP between ... and ... order by MYTIMESTAMP

Dann hast du die gewünschten Daten direkt und in der gewünschten Reihenfolge (Auf MYTIMSTAMP sollte natürlich ein Index liegen).

[jobo]

Zitat von Der schöne Günther:

Je weiter ich stöbere, desto mehr gefällt mir allerdings die Advantage DB: Wer brennend Interesse hat, kann hier den kurzen Artikel
..

Klingt interessant. Ich hab noch nie mit ADV gearbeitet.
Was Du erreichen möchtest geht tatsächlich mit jeder DB. Was Deine Zitate von ADV angeht klingt das für mich etwas nach festen Speichergrößen (wie file of record).
Der "direkte" Zugriff wäre also u.U. mit etwas Platzverschwendung erkauft.. aber das ist reine Vermutung und muss ja auch nicht stören.

[p80286]

Also ISAM ist ja schon etwas älter

Zitat:

Index Sequential Access Method (ISAM) ist eine von IBM Ende der 1960er Jahre entwickelte Zugriffsmethode für Datensätze einer Datei, die sowohl (sortiert) sequentiellen als auch wahlfreien (random) index-basierten Zugriff zulässt.

wikipedia

Wenn man so will ist dies die Vorstufe zu den relationalen SQL-Datenbanken.
Hierbei hat jeder Datensatz einen Eintrag im "Basisindex" und sei dies die Satznummer. Und nur über diesen Index ist die "Natural Order" vorgegeben. Natürlich können auch weitere Indizes generiert werden.

Insbesonders für Deine Anforderung "einen Datensatz oft ablegen" ist ISAM ausreichend, da Relationenoverhead wegfällt.

@jobo
file of record ist genau die richtige Beschreibung. Allerdings gibt es auch Implementierungen, bei denen im Indexrecord nicht nur die Startadresse sondern auch die Länge abgelegt wird. Somit kann man auch auf Strings indexsequenziell zugreifen.


Gruß
K-H

[Perlsau]

Zum Punkt Backup:

Bei DB-Applikationen, die von wenig versierten Anwendern oder gar Daus bedient werden sollen, baue ich immer eine automatische DB-Sicherung ein: Wahlweise in den Optionen einstellbar gleich nach dem Programmstart oder bei Programmende auszuführen. Beim Einsatz einer Firebird-DB gestaltet sich das im Falle einer Single-User-App besonders einfach: Vor dem DB-Connect bzw. nach dem Disconnect wird einfach die DB-Datei an einen frei wählbaren Ort kopiert. Bei Multi-User-Apps muß man selbstverständlich ein "richtiges" Backup durchführen, da man eine geöffnete DB nicht kopieren sollte.

[DeddyH]

Ich nehm dafür immer gbak bzw. Komponenten, die darauf aufbauen. Das hat ganz nebenbei auch noch den Vorteil, dass das Backup gepackt wird.

[mkinzler]

Zitat von DeddyH:

Ich nehm dafür immer gbak bzw. Komponenten, die darauf aufbauen. Das hat ganz nebenbei auch noch den Vorteil, dass das Backup gepackt wird.

Und zumindest der Backup auch im Betrieb funktioniert.