Danke für die Antworten
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.
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?
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
Deswegen das explizite Interesse für Dinge, die bei
RAD Enterprise wohl schon "dabei" sind.
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.