Lokale Archivierung, chronologisch geordnet. Welches DBMS brauche ich?

[Der schöne Günther]

Hinweis: Ich habe bewusst nicht das Datenbanken-Unterforum gewählt da dieses sich mit konkreten Problemem und deren Lösungen beschäftigt. Ich hoffe, das war richtig.

Da ich im Titel schon nach einer konkreten Technologie frage, die ich einsetzen soll ist der Glaubenskrieg möglicherweise schon vorprogrammiert. Ich möchte erst einmal vorstellen, was ich vorhabe, und in welchen drei Dingen ich Rat brauche:

Ich möchte Sätze von Messwerten langzeit-archivieren. Wir sprechen hier über ein, zwei, vielleicht drei Jahre. Darüber hinaus macht es keinen Sinn mehr. Ein Satz von Messwerten ist wiederum mit einem Satz von ganz anderen Messwerten verknüpft. Beide beginnen und enden zur selben Zeit. Und in dieser Zeitspanne fallen einzelne, für sich genommene Ereignissee an. Die möchte ich auch mitloggen.
Auf Dauer ist mit ein paar zehn- oder hunderttausend solcher Sätze an Messwerten zu rechnen. Fast schon ein Stack - Bereits geschriebene Datensätze werden nicht mehr verändert.

Ich habe nun praktisch null Praxiserfahrung mit Datenbanken: Mehr als wahllos Daten in bereits bestehende Postgres, Advantage oder SQLite-DBs werfen und lesen habe ich nie gemacht. Nun geht es um den Aufbau eines neuen Systems.

1a) Allen Datensätzen haftet bei ihrem Eintrag in die DB der momentane Zeitstempel an. Soll heißen: Die "natural order" in der DB ist ihre wirkliche chronologische Reihenfolge. Nehmen wir an, ich möchte nun alle Datensätze, die zwischen November 2013 und Februar 2014 liegen. Was muss ich tun, damit das DBMS so schlau ist, sich nicht jeden der Datensätze anzuschauen, ob er in den gewünschten Zeitrahmen passt? Reicht die Verwendung eines nativen "TIMESTAMP"-Datentyps für eine Spalte? Muss ich mehr beachten? Oder habe ich sowieso keinen Einfluss, was sich hinter den Kulissen abspielt und muss mit wachsender DB hilflos zuschauen, wie die Performance immer weiter in den Keller geht?

1b) Die Daten sollen lokal auf einer einzigen Maschine gespeichert werden. Geht diese in Flammen auf, hat man eben Pech gehabt :o. Oder vorher eine "Kopie" der Datenbank auf einen Netzwerkpfad, USB-Stick oder gesichert. Es sollte sich so einfach lösen lassen, wie eine (oder mehrere wenige) Datei im Windows-Dateisystem zu kopieren. Die "Wiederherstellung" sollte sich auch vom Kunden selbst bewerkstelligen lassen. Wenn ich, wie bsp. bei SQLite, eine einzelne Datei kopiere und habe wieder den gesicherten Stand - Perfekt.

2) Das Projekt wird momentan nur mit dem RAD Studio XE4 Enterprise gebastelt, deshalb wäre es mir lieb, auch mit Delphi oder dem C++ Builder direkt ewtas basteln zu können. Ist zwar kein Muss; Wenn ich allerdings sehe, was für Mengen an DB-Funktionalität und klangvolle Namen (FireDAC, dbExpress, InterBase,...) einem von Embarcadero gleich um die Ohren gehauen werden, wäre es natürlich gut, gleich so etwas, das bereits "dabei" ist, zu nutzen.
Bislang kommt als lokale DB der Advantage Local Server zum Einsatz. Der sieht schonmal nicht übel aus. Vor SQLite hätte ich, aufgrund der Datenmengen, etwas Angst.

Ich frage nun nach einer konkreten Technologie, mit welcher ich Punkte 1a) und 1b) am besten erreiche. Ist die Advantage Local DB geeignet? Scheidet SQLite aufgrund der Datenmengen aus? Ich habe null Praxiserfahrung und langsam gehen mir auch die Ideen aus wie man ein "Ich habe keine Ahnung, sagt mir einfach, was ich nehmen soll" weiter hinter blumigen Worte verstecken kann.

Daher bedanke ich mich fürs Lesen und harre weisen Ratschlägen.

[joachimd]

Da Du schon speziell nach dem ALS fragst: Ein Index auf einem Timestamp-Feld genügt, um auch bei vielen tausend Datensätzen schnell filtern zu können (1a). Zur Datensicherung (1b) einfach das Programm beenden und den Daten-Ordner weg kopieren - geht auch hervorragend als batch mit gleichzeitigem packen danach:

Code:

@echo off
cls
set ordnername=data
set archivname=MyBackup%date:~6,4%%date:~3,2%%date:~0,2%.rar
set password=-hpGEHEIM

"%programfiles%\winrar\rar.exe" a -r %password% %archivname% %ordnername%
copy %archivname% c:\mnt\myotherdevice
rem del /F /S /Q %archivname%
pause

[mkinzler]

Es gibt keine "natural order":
-Beim Löschen entstehen Lücken, welche später gefüllt werden.
-Abfragen verwenden Indizes, so dass Ergebnisse eine andere Reihenfolge haben können.

Jedes aktuelle DBMS sollte deinen Anforderungen genügen.

zu 1a) TIMESTAMP sollte reichen; Index auf Spalte
zu 1b) Entweder Sicherung auf Netzpfad oder Replikation

zu 2) Mit FireDAC sollte jedes aktuelle DBMS unterstützt werden. Als Datenbanksystem würde auf Firebird verwenden ( wenn dich nicht stört das es OpenSource ist; für manche ist das ja ein absolutes NoGo, da kein garantierter Support und Weiterentwicklung) sonst halt MSSQL oder ein schon vorhandenes DBMS ( z.B. Oracle, dann gibt es vor Ort einen der sich damit auskennt - sonst lieber nicht).
Aber das verwendete DBMS ist eine Geschmacksfrage, bei der es viele verschiedenen Meinungen gibt.

[generic]

Als mögliche Techniken des Datenbanksystems schmeiße ich mal Tabelle Partitionierung z.B. nach Jahren vor oder einfach BigData/NOSQL Ansätze (Map and Reduce).

[Der schöne Günther]

Danke für die Antworten :thumb:

Zitat:

Zitat von mkinzler (Beitrag 1226988)

Es gibt keine "natural order":
-Beim Löschen entstehen Lücken, welche später gefüllt werden.

Gerade das ist, soweit ich das durch Hörensagen mitbekommen habe, bsp. bei der Advantage DB nicht der Fall. Die Reihenfolge bleibt erhalten, die Datensätze werden noch nicht einmal gelöscht, sondern nur ein "deleted"-Flag gesetzt.

Das momentane Produkt nutzt auch genau das aus, indem es sich die RowIDs als Pseudo-Fremdschlüssel auf andere Tabellen nutzt. Und das funktioniert seit etlichen Jahren.

Zitat:

Zitat von joachimd (Beitrag 1226986)

Da Du schon speziell nach dem ALS fragst: Ein Index auf einem Timestamp-Feld genügt, um auch bei vielen tausend Datensätzen schnell filtern zu können

Bei einem kleinen Test gestern mit einer Advantage 9.0 habe ich innerhalb von einer Zehntelsekunde alle Datensätze innerhalb eines Zeitbereichs aus einer DB von ca 85.000 Datensätzen geholt. Das sah schon sehr gut aus, aber trotzdem kann ich bei einer größeren DB und Verknüpfung von zwei oder drei Tabellen nur ungerne ein, zwei Sekunden warten. 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?

Ihr beide sprecht vom einfachen Kopieren von Daten, da hake ich lieber gleich nach: Vor vielen Wintern hatte ich unter Java Kontakt mit Postgres-Datenbanken, Linux wie Windows. Ich habe irgendwie noch im Hinterkopf, dass sich gerade unter Windows in der Registry und Systemverzeichnissen alle möglichen Einstellungsfitzel verteilen und eine Datenbank sich nicht einfach in einen Koffer packen und transportieren ließ. War das eine hässliche Ausnahme?

Zitat:

Zitat von mkinzler (Beitrag 1226988)

Aber das verwendete DBMS ist eine Geschmacksfrage, bei der es viele verschiedenen Meinungen gibt

Vielleicht hätte ich noch erwähnen sollen, dass dafür möglichst nichts gezahlt werden sollte :wink:
Deswegen das explizite Interesse für Dinge, die bei RAD Enterprise wohl schon "dabei" sind.

Zitat:

Zitat von generic (Beitrag 1226989)

Als mögliche Techniken des Datenbanksystems schmeiße ich mal Tabelle Partitionierung z.B. nach Jahren vor oder einfach BigData/NOSQL Ansätze (Map and Reduce).

Zu nicht-relationalen Datenbanken habe ich noch nicht einmal Theoriewissen, deshalb scheidet das leider vorerst vollkommen aus. :|

[jobo]

"jedes aktuelle RDBMS..."
Also Oracle kann ich nicht empfehlen. Ein Backup mal eben durch kopieren der Tablesspace Files anzufertigen kann gut in die Hose gehen..

[mkinzler]

Zitat:

Gerade das ist, soweit ich das durch Hörensagen mitbekommen habe, bsp. bei der Advantage DB nicht der Fall. Die Reihenfolge bleibt erhalten, die Datensätze werden noch nicht einmal gelöscht, sondern nur ein "deleted"-Flag gesetzt.

Das momentane Produkt nutzt auch genau das aus, indem es sich die RowIDs als Pseudo-Fremdschlüssel auf andere Tabellen nutzt. Und das funktioniert seit etlichen Jahren.

Dann scheint es bei ADS im besonderen so zu sein. Es wird aber auch dort eine Funktionalität geben (Zap o.ä) um die Datensätze zu löschen.

Zitat:

Ihr beide sprecht vom einfachen Kopieren von Daten, da hake ich lieber

Ich sprach von Sicherung oder Replikation, beides ist nicht einfaches Kopieren. Bei der Sicherung wird im Betrieb eine Kopie gezogen ( normalerweise in einen besonderen Format). Bei Replikation werden Änderungen auf ein anderes System übertragen ( kann auch eine zentrale DB für mehrere lokalen DBs sein, welche die Daten der lokalen umfasst).

Zitat:

Also Oracle kann ich nicht empfehlen. Ein Backup mal eben durch kopieren der Tablesspace Files anzufertigen kann gut in die Hose gehen.

Ich würde von Kopieren auch grundsätzlich abraten.

[jobo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1226990)

Danke für die Antworten :thumb:

Zitat:

Zitat von mkinzler (Beitrag 1226988)

Es gibt keine "natural order":
-Beim Löschen entstehen Lücken, welche später gefüllt werden.

Gerade das ist, soweit ich das durch Hörensagen mitbekommen habe, bsp. bei der Advantage DB nicht der Fall. Die Reihenfolge bleibt erhalten, die Datensätze werden noch nicht einmal gelöscht, sondern nur ein "deleted"-Flag gesetzt.

Je nach Datentyp / Timestamp Genauigkeit und Frequenz der Messwerte sorgt nicht mal der Timestamp für die "natural order".
Dabei muss man im Grunde sogar darauf achten, ob Speichergenauigkeit und Auflösung des generierten Zeitwerts ausreichen.
Sicherheitshalber empfiehlt sich eine Sequenz / AutoID an der Stelle.

[mkinzler]

Zitat:

Sicherheitshalber empfiehlt sich eine Sequenz / AutoID an der Stelle.

Das würde ich zusätzlich immer tun. Der Einsatz von syntetischen Schlüsseln ist aber auch eine Glaubensfrage.

[Der schöne Günther]

Danke für die Antworten soweit.

In Sachen "Sicherung" war ich möglicherweise zu ungenau: Das Exportieren von ge-backupten Daten und Wiederherstellen sollte sich entweder über eine mit der heißen Nadel gestrickten Anwendung von mir oder direkt über den Windows Explorer bewerkstelligen lassen. Den Nutzer will ich nicht direkt an an DB-Verwaltungssoftware lassen, damit käme er auch nicht zurecht.

[p80286]

Zitat:

Zitat von Der schöne Günther (Beitrag 1226990)

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:

Zitat von Der schöne Günther (Beitrag 1227008)

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:

Zitat von Der schöne Günther (Beitrag 1227008)

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:

Zitat von Der schöne Günther (Beitrag 1227008)

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:

Zitat von DeddyH (Beitrag 1227020)

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.

[DeddyH]

So isses.

[hstreicher]

Zitat:

Zitat von Perlsau (Beitrag 1227016)

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.

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.

[Der schöne Günther]

Ich kenne Firebird jetzt nicht. Müsste man die Befürchtung auch haben, wenn die ganze Datenbank in die Anwendung eingebettet ist (wie bsp. SQLite oder auch mit Advantage möglich)? Eigentlich nicht, oder?

[p80286]

Wie sieht denn die eigentliche Anwendung aus?
Hast du einen PC/Arbeitsplatz, der die Daten an die Datenbank liefert oder läuft das im "Multiuserbetrieb". Ist letzteres der Fall, benötigst Du eigentlich einen eigenständigen Server, sprich mitembedded ist Essig.

Gruß
K-H

[Der schöne Günther]

Nein, kein Multi-User-Betrieb. Nur ein lokales Datengrab. Die Daten liegen dort, die Daten schaut man sich dort an (falls überhaupt).

Auf lange Sicht wird garantiert die Anforderung kommen, die Daten nicht nur auf der lokalen Maschine, sondern auch anderswo anzeigen zu können. Das ginge aber erstens auch mit einem "veralteten" (sprich: duplizierten) Datensatz und zweitens lässt das auch die Lizenz des momentan favorisierten Advantage DBS einen Zugriff von außen nicht zu. Deshalb: Reiner Single-User-Betrieb. 8-)

[Uwe Raabe]

Um mal wieder etwas Seitenwind einzubringen: Man kann das auch mit Delphi-Bordmitteln und TClientDataSet erledigen. Wenn die jährliche Datenmenge einigermaßen im Rahmen bleibt, kann man für jedes Jahr eine eigene Datendatei anlegen. Das macht zwar die Selektion geringfügig aufwändiger, weil man erst den Dateinamen anhand des Jahres bestimmen muss, aber das Sichern und insbesondere auch das Löschen alter Daten (jahresweise) gestaltet sich als wesentlich einfacher. Unschön wird es allerdings, wenn man über mehrere Jahre selektieren will - dafür müsste man die Daten lokal zusammenhängen. Dafür ist es aber auch eine Butterbrot-Lösung, die zu dem noch ohne externe DLLs (MidasLib einbinden) oder Fremdkomponenten auskommt.

[stahli]

Zitat:

Zitat von Der schöne Günther (Beitrag 1227044)

Ich kenne Firebird jetzt nicht. Müsste man die Befürchtung auch haben, wenn die ganze Datenbank in die Anwendung eingebettet ist (wie bsp. SQLite oder auch mit Advantage möglich)? Eigentlich nicht, oder?

Kannst Du das nochmal anders fragen? ;-)

Die Datenbank liegt irgendwo (MyData.fdb) und entweder ist auf dem System ein Datenbankserver installiert oder Du legts ein paar DLL´s zur Exe. Direkt Eingebettet ist die Datenbank dabei nicht in Dein Projekt. Es geht nur darum, dass auf Deinem System kein ("globaler") FirebirdServer installiert sein muss.

Hast Du eigentlich schon mit SQL-Statements gearbeitet?

[arnof]

... sorry selbst Löschung die Sonne hat mit geblendet und ich habe mist geschrieben ....

[mkinzler]

Zitat:

Zitat von arnof (Beitrag 1227059)

... sorry selbst Löschung die Sonne hat mit geblendet und ich habe mist geschrieben ....

Du hast die Sonne gelöscht? :mrgreen:

[Der schöne Günther]

Zitat:

Zitat von stahli (Beitrag 1227055)

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?

Zitat:

Zitat von stahli (Beitrag 1227055)

Hast Du eigentlich schon mit SQL-Statements gearbeitet?

Ist "SQL-Statement" jetzt ein ganz spezieller Begriff? :oops:
Die Theorie zu relationalen DBMS habe ich wohl verinnerlicht, und von den DML und DDL-Kommandos die ihr Profis jeden Tag absetzt kenne (und nutze) ich wahrscheinlich 15%. Mir fehlt einfach nur die Kenntnis von konkreten Produkten und regelmäßiger Alltagseinsatz abseits von SQLite.

[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:

Zitat von mkinzler (Beitrag 1227067)

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 :oops:


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:

Zitat von hstreicher (Beitrag 1227041)

Zitat:

Zitat von Perlsau (Beitrag 1227016)

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:

Zitat von Der schöne Günther (Beitrag 1227065)

Zitat:

Zitat von stahli (Beitrag 1227055)

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:

Zitat von Der schöne Günther (Beitrag 1227072)

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

Zitat von taveuni (Beitrag 1227094)

Zitat:

Zitat von Der schöne Günther (Beitrag 1227072)

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

Zitat von Der schöne Günther (Beitrag 1227101)

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