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
. 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.