MSSQL 2005 Datenaufkommen udn Zukunftsfragen?

Hallo,
ich bastele gerade an einer Webanwendung. Ich soll Buchungen von Kunden abspeichern. Modelliert, normalisiert… wir buchen und die Datensätze landen in 7 Tabellen. Sorgen habe ich bei der Positionen Tabelle. Ich rechne mit einem Datenaufkommen von etwa 50 Millionen Datensätze im Jahr. Die Lösung wird voraussichtlich 5 Jahre halten müssen.

  1. Hat jemand Erfahrungen mit solchen Datenmengen?
  2. Mein zweites Problem ist die Buchungsänderung. Ich soll nach jeder Änderung den alten Stand einfrieren. Mein Auftraggeber möchte jederzeit sehen, wie sich die Buchung wann geändert hat. Da ich bei jeder Buchung mit bis zu 50 Datensätzen im Schnitt rechne, kann ich nicht jedes Mal alle Positionen einfrieren. Der Ansatz, nur geänderte Positionen einzufrieren hat folgenden Nachteil. Angenommen die Buchung ist in der Version 5 (angefangen bei 1), ich kann die Version 3 erst wiederherstellen, in dem ich aus der Version 1 ausgehe, die Änderungen der Version 2 darauf anwende, dann die der dritten Version. Das macht den Algorithmus für den Programmierer komplexer. Mein Horror fall ist die Version 10 zum Beispiel wiederherstellen zu müssen, es wären dann 9 Durchläufe. Ich spiele also mit dem Gedanken die 50 Positionen bei Änderung über eine „Datenkonvertierungsklasse“ in ein String umzuwandeln, und das ganze in einem Datensatz in einem nvarchar(max) Feld abzuspeichern. Da ich in diesen Datensätzen nie suchen werde, sondern immer nur eine Version auslesen werde, kommt es mir effektiver als das „positionsweise“ Einfrieren der Datensätze.
    Jemand eine Idee, oder herrscht eher „Kopfschütteln“ bei diesem Ansatz?
    Bin für jede Anregung oder Meinung dankbar

Hallo,
zu 1)
Nein, sorry.
zu 2)
Macht es einen Unterschied, ob eine Programmlogik in einer Schleife durch 1,3 oder 10 Durchgänge durchläuft. Sprich: Du schreibst einmal eine Logik, die einen Datansatz von Version n auf Version (n+1) hieft, und dann wendest du sie per Schleife an…
Das mit dem String klingt eher wie ein Workaround (irgendwie wie eine Übergangslösung), aber einen viel besseren Vorschlag habe ich nicht.
Maximal noch, immer den ganzen Datensatz neu abspeichern, dann kannste dir auch Pinkt eins sparen, nur das würde das Datenaufkommen massiv erhöhen, daher eigentlich auch unpraktikabel…

Gruß,
AlexR

Hallo Programmierer,

die Erfahrung habe ich nicht mit MSSQL, aber zur Beantwortung fehlen einige Angaben: Wie lange sollen Buchungen denn änderbar sein? Wenn die Datenmenge zu groß für ein SELECT wird (hängt aber stark von den Zugriffswegen ab), kann man alte Datensätze (Monatlich, jährlich) in Tabellen (z.B. mit Postfix jjjjmm) verschieben. Die Gesamtsicht kann man über eine View sicherstellen.

Deine Argumentation mit den geänderten Position verstehe ich nicht ganz. Warum legst Du nicht für jede Datensatz ein gueltig_von und gueltig_bis an. Wenn ein Datensatz (z.B. Buchungsposition) änderst, setzt Du im alten Datensatz mit aktueller Uhrzeit in gueltig_bis und legst dann einen neuen Datensatz mit gueltig_von mit den gueltig_bis des alten Datsatzes an.

MfG Georg V.

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]