Wie am besten sehr viele Datensätze in SQLAlchemy speichern

[snafu]

Mein Gedanke war halt, dass sich alle Angaben auch mal ändern können und man dann auch wirklich jede Änderung archivieren möchte. Beispiele für Änderungen an den Stammdaten: Umzug des Users, Umbenennung des Accounts, Verschreiber beim Geburtsdatum, neue Email-Adresse, etc. Es ist halt abhängig davon, ob man sich auf bestimmte Updates beschränken möchte (z.B. nur neue Forumsbeiträge) oder ob man wie gesagt alles, was geht, mitloggen will.

[/me]

Mein Gedanke war halt, dass sich alle Angaben auch mal ändern können und man dann auch wirklich jede Änderung archivieren möchte.

Eine klassische Vorgehensweise wäre es, dafür Trigger in der Datenbank zu erstellen und diese das Logging bzw. die Archiwierung übernehmen zu lassen.

[jerch]

Wie gesagt: Ich würde eine Tabelle machen, die die aktuellen Daten beinhaltet. Dort existieren genau so viele Zeilen wie Benutzer. Im Grunde kannst du es bestimmt dort bei deiner bisherigen Datenstruktur belassen. Was dazu kommt, wäre halt die zweite Tabelle, die mit Vergangenheitswerten gefüllt wird - quasi dein Archiv. Ins Archiv käme immer der Stand einer Zeile, der vor einer Änderung existiert hat. Im Archiv würde ich die Daten einfach so runter schreiben mit dem Zeitstempel des Eintragens als Primärschlüssel. Dieser Zeitstempel markiert also den Zeitpunkt bis zu dem die Daten als aktueller Wert existiert haben. Sicherlich sind aber auch andere Lösungen denkbar.

Ich halte dieses Vorgehen auch eher für ungewöhnlich.

@Dami123:
Trenne die Daten eher nach Stammdaten (wenig Veränderung) und Bewegungsdaten, wie von /me schon vorgeschlagen wurde - also Tabelle1 mit Feldern wie Name, Adresse, Schuhgröße. Da kommen ALLE Nutzer rein. Tabelle2 mit den Bewegungsdaten enthält dann nur die schnell veränderlichen Werte mit Fremdschlüssel auf den Nutzer aus Tabelle1. Ein Nutzer, der nix macht, taucht dort nicht auf. Auch solltest Du versuchen, weitestgehend zu normalisieren. (Optimierungen mit lookup tables würde ich erst machen, wenn das Problem als Flaschenhals identifiziert wurde.)
Über die Anzahl der Reihen in einer Tabelle musst Du Dir zunächst keine Sorgen machen, solange Du Indices nutzt und die Anfragen nicht böse verschachtelte JOINs, Subselects oder UNIONs sind. Diese sind sehr RAM-hungrig, wenn die DB auslagern muss, wird das zum Performancekiller. UNIONs führen zusätzlich zu Problemen mit den Indices, was dann Rechenzeit kostet.
Das weitere Vorgehen mit den alten Daten in der Bewegungstabelle würde ich vom use case abhängig machen. Brauchst Du die nicht mehr - löschen. Sind die Zugriffe darauf selten, lohnt das Wegschreiben in ein Archiv. Falls der Server sich nachts langweilt, ist das ein guter Zeitpunkt hierfür usw.

[Dami123]

Die Unterteilung werde ich in Stammdaten und Bewegungsdaten machen. Wobei sich die Stammdaten nicht ändern lassen, wie z.B. die Userid und Registrierungsdatum und Bewegungsdaten, die sich nicht nur ändern lassen, sondern auch werden.
Der Zugriff auf die Bewegungsprofile wird per Userid und Timestamp erfolgen und keine UNIONs erhalten. Da es sich um Userstatistiken handelt, werden diese nicht gelöscht. Der Transfer auf eine Archiv Datenbank bzw. Tabelle könnte sich nach einem gewissen Zeitraum lohnen, da die Standardeinstellung für die durch die Daten erzeugten Diagramme auf 30 Tage festgelegt wird.

Danke für den Einwand.