Archivnutzung verbessern

[alexj]

Hat sich erledigt, ich bin blinde Nuß!.
Sorry. Hab es gefunden!

Es wäre schön, wenn ich ein Archiv anlegen könnte und dort alle älteren Daten hineinschieben kann.
Nicht wie bisher immer eine neue Archivdatei pro Archivierung anlegen, sondern nur eine Archivdatei, die mit jedem hinzufügen ein neuen und die vorhandenen Archivierten Daten enthält, sodass man nur einen Ort für arcivierte Daten hat.

Gruß
AJ

[alexj]

PS: Kann man die Daten aus einem Archiv wieder importieren? Ich hab das nicht gefunden!

Via "Daten wiederherstellen" wird vermutlich alles neuere in der aktuellen DB gelöscht. Also keine Option, Oder?

[heweni]

Nein, kann man nicht wieder importieren.
Deswegen gut überlegen, ob du einen Haken setzt bei: "Archivierte Daten unwiderruflich aus Datenbank entfernen".

Archivierte Daten kann man zwar noch anzeigen, auch Auswertungen drüber laufen lassen (nicht zusammen mit nicht archivierten Daten), aber nicht mehr ändern, oder zurück in die normale Datenbank spielen.

[FFF]

Nein, kann man nicht wieder importieren.
Deswegen gut überlegen, ob du einen Haken setzt bei: "Archivierte Daten unwiderruflich aus Datenbank entfernen".

Archivierte Daten kann man zwar noch anzeigen, auch Auswertungen drüber laufen lassen (nicht zusammen mit nicht archivierten Daten), aber nicht mehr ändern, oder zurück in die normale Datenbank spielen.

Ich habe eben mal die Dateien angesehen, 17 Jahre, rd. 20 Konten, resultieren in einer DB-Größe von rd. 20MB - das ist schlicht "nix" in halbwegs modernen Zeiten, weder für die Datenbank, noch für's Dateisystem und schon gar nicht für den Speicher.
Folgerung:
* Archiv kann man allenfalls als Backupersatz betrachten
* Alf könnte/müßte an der Datenbankseite noch merklich drehen, ein modernes System sollte nicht > 10sec brauchen (von SSD), um etwa 15k Umsätze für die Listendarstellung zu ziehen...

[heweni]

* Alf könnte/müßte an der Datenbankseite noch merklich drehen, .

Richtig. Ich hoffe ALF bleibt da noch dran. PostgreSQL (hattest du mal vorgeschlagen), oder MariaDB würde ich dem MS-SQL-Server vorziehen. SQLite wird immer langsamer, je mehr Daten.

Die Archiv-Funktion ist noch sinnvoll, wenn jemand vergangene Jahre abgeschlossen hat und sicherstellen will, dass da nichts mehr dran geändert wird. Dann kann auch SQLite wieder freier atmen.

Ich hatte gestern die Archivierung erstmals ausprobiert. (Wegen diesem Thread).
Eigentlich nicht schlecht. Man kann jederzeit zur Archivanzeige umschalten und Auswertungen fahren.
Die nicht archivierten Daten sind dann nicht im Zugriff, d.h. leider keine Auswertung die archvierte und nicht archivierte Zeiträume enthalten soll.

[alexj]

Mittlerweile mache ich meine Überweisungen wieder mit AB6, weil AB7 sooo langsam geworden ist.
jeder Wechsel eines Kontos oder eine gelesen Änderung dauert 5-10 Sekunden.

Vergleich, jeweils Identisches Konto auf dem gleichen Rechner, DB liegt ebenfalls auf dem gleichen Server!

AB7: Abruf EINES Kontos (ohne neue Umsätze) dauert ca. 20-25 Sek.
AB6: Abruf EINES Kontos (ohne neue Umsätze) dauert ca. 10 Sek.
Mit neuen Umsätzen ist die Differenz noch größer!

AB7 Öffnen der Umsätze: 10 Sek.
AB6 Öffnen der Umsätze: 1 Sek.

Aufruf der Übersichtsseite:
AB7 5 Sek.
AB6: unter 1 Sek.

@Alf: Bitte bringt möglichst bald eine Lösung dafür.

[ALF]

Hallo,

wir arbeiten bereits an einer SQL-Server Lösung.
In wenigen Wochen sollte diese als Vorab-Version verfügbar sein.
Wer mit uns bereits Kontakt wegen langsamer DB bzw. SQL Server hatte, sollte dann vorauss. im März eine entsprechende Vorab-Version zugeschickt bekommen.

Gruß,
ALF

[alexj]

Super. Danke.

[alexj]

wir arbeiten bereits an einer SQL-Server Lösung.

Darf ich fragen mit welchem SQL-Server?

[FFF]

wir arbeiten bereits an einer SQL-Server Lösung.

Darf ich fragen mit welchem SQL-Server?

Vernünftigerweise vermutlich mit einer "agnostischen" Variante, also schlicht SQL nach Standard. Die Bedürfnisse eines Programms wie Alf sollten sich damit problemlos befriedigen lassen, - ob der User dann Postgres, MySQL, MariaDB, SQL-Server, Firebird oder wie sie sonst auch heißen, installiert hat, sollte dann schlicht egal sein...

[alexj]

Das wäre gut. Schaun mer mal...

[claas]

Sie haben sich für den Microsoft SQL-Server entschieden. Den gibt es Gott sei Dank auch für Linux, die Schmerzen halten sich für mich daher in Grenzen.

[FFF]

Sie haben sich für den Microsoft SQL-Server entschieden.

Ich frage mich nur, warum. Für das, was Alf datenbanktechnisch veranstaltet, brauche ich nun wirklich keine proprietären Seitenwege, das kann SQL. Und dann sollte es kein Problem sein, per angepaßtem Connectionstring auch mit non MS Produkten zusammenzuarbeiten...
BTW, heute kam beim Java Update der freundliche Hinweis, dass für Endverbraucher selbige "noch bis 2020" angeboten würden, für geschäftlichen Einsatz aber schon kommendes Jahr eine "kommerzielle Lizenz" nötig wird. Noch Fragen?

[DerBene]

Hallo,
inzwischen ist es bei ebenfalls soweit, dass mir die Geschwindigkeit massiv auf die Nerven geht.
Ich denke inzwischen öfter darüber nach, mich wieder über die Homepage der Bank dem Onlinebanking zu widmen, weil ALF Banco 7 unglaublich langsam ist.
Gibt es Fortschritte in der Entwicklung der SQL-Integration?

Ich möchte mich nur ungerne nach einer anderen Lösung umschauen müssen.

Viele Grüße
Bene

[alexj]

Melde dich per mail beim support.
Die beta ist meiner Meinung nach stabil genug für den produktiv einsatz.