Massendaten täglich in eine DB speichern - Was macht Sinn?

[alzaimar]

Zitat:

Zitat von Piro (Beitrag 1064156)

@alzaimar: könntest du mir eventuell einen beispielhafteren Code geben und kurz erklären was der macht. Der Ansatz ist echt gut.

1. Zeile: Erzeugen einer Tagestabelle auf Grundlage einer Vorlage.
2. Zeile: Wir erzeugen einen Index
3. Zeile: Wir importieren eine CSV-Datei wuppdiwupp-und-eins-fix-drei 1:1 in die Tagestabelle

Die genaue Syntax kann ich morgen posten. Hier habe ich sie nicht. Du kannst sie aber selbst ergoogeln. "MSSQL BULK INSERT"

[Sir Rufo]

Code:

BULK INSERT

in eine frische Tabelle ist das richtige Stichwort.

Nehmen wir mal an deine Tabelle mit den Daten heißt

Code:

IMPORT_DATA

Dann würde ich wie folgt vorgehen:
1. CSV-Daten per BULK INSERT in die Tabelle

Code:

IMPORT_DATA_<YYYYMMDD>

(ersetze "<YYYYMMDD>" mit dem Tagesdatum) importieren.
2. Ist alles korrekt importiert worden dann innerhalb einer Transaktion

Code:

DROP TABLE IMPORT_DATA;
EXEC sp_rename '<Schema>.IMPORT_DATA_20101126', 'IMPORT_DATA';

Sollte der Import mal nicht funktionieren, dann sind die alten Daten noch da.

Wenn die Daten auch noch für einen Zeitraum x archiviert werden sollen, dann erzeuge eine Archiv-Tabelle mit folgenden Feldern:

Code:

Zeitpunkt [PRIMARY KEY]
ZeitID [PRIMARY KEY]  // der Index aus IMPORT_DATA
// jetzt die restlichen Felder aus IMPORT_DATA

Über den Zeitpunkt kannst du dann Reorganisieren.

Sollte es Performance-Probleme geben, ist es ratsam diese Archiv-Tabelle auf einer anderen Festplatte anzulegen.

[R2009]

Hi Piro,

nur ein kleiner Hinweis:
ich weiss nicht wie das bei MSSQL gehandhabt wird aber bei SQlite ist es so, dass gelöschte Daten nicht verschwinden, sondern nur als gelöscht markiert werden. Ein compress ist bei SQlite, zumindest von wrapper seite aus, nicht möglich (nur aus dem Kommandozeientool). Wir sind deshalb, bei SQlite, auch dazu übergegngen ganze Tabellen zu löschen,die Struktur neu zu erstellen und dann die Daten neu reinzuschreiben.Bei uns geschieht das im Monat einmal, ist also ein vergleichsweise geringer Aufwand.
Ein viel grösseres Problem als die überlaufende ID sollte die absolute Grösse deiner DB darstellen.

Grüsse
Rainer

[taveuni]

Ist ja alles ganz nett.
Aber wenn die Daten wirklich nicht mehr gebraucht werden
bitte den Tabelleninhalt mit TRUNCATE löschen.
Die Indizies bleiben erhalten, der Speicherplatz wird freigegeben
und die Aktion 100'000 Records zu löschen dauert ca 0.0023 Sekunden auf unserem Sql Server.

Also wo ist das Problem?

[alzaimar]

Zitat:

Zitat von taveuni (Beitrag 1064193)

Also wo ist das Problem?

An ganz anderer Stelle. Lies einfach den Thread durch.

[taveuni]

Zitat:

Zitat von alzaimar (Beitrag 1064195)

Lies einfach den Thread durch.

Hab ich nun noch mal gemacht.
Ich hatte das ursprüngliche Problem so interpretiert dass der Thread Ersteller
Daten in einer Tabelle hat die er nicht mehr braucht und mit neuen füllen will.
Bedenken lagen dann irgendwo bei einem Ueberlauf des Primärindexes.
Ausserdem waren dann noch Hinweise auf die Schnellste Methode.

Ich habe dann darauf hingewiesen das TRUNCATE diese beiden Probleme lösen würde.

Aber vielleicht sollte ich mich noch mehr zurückhalten und wieder arbeiten.

Sorry.

[pixfreak]

Moin zusammen,

wenn wirklich richtig löschen, dann Truncate, wie bereits gesagt....

Aber wie der Teufel es will, brauchst Du die Daten in zehn Jahren doch noch mal.
Also ein PK auf bigint Basis, bei (signed) kann er 9.223.372.036.854.775.808 Werte annehmen, bevor er überläuft (ins negative...)
Bei 100.000 Daten täglich sind das:

92.233.720.368.548 Tage

252.695.124.297 Jahre

252.695.124 Jahrtausende

...

Selbst wenn Dein Programm länger als Du lebst am Laufen bleiben muss, wird es bei selbst x mal sovielen Daten wie jetzt die jetzige und zukunftsnahe Computerarchitekturen locker überleben.:shock:

Ich würde daher auch noch das Datum speichern (vielleicht in einer zweiten Tabelle) und man kann auf die Daten dann doch noch später zugreifen oder ab einer bestimmten Zeit löschen.

Nebenbei: Maximales erreichbares Alter unserer Sonne: 11,112 Milliarden Jahre (lt. Wikipedia) Danach, bzw. "kurz" davor ist es eh egal... :wink:


VG Pixfreak

[Satty67]

[OT]

Zitat:

Zitat von pixfreak (Beitrag 1064222)

Nebenbei: Maximales erreichbares Alter unserer Sonne: 11,112 Milliarden Jahre (lt. Wikipedia) Danach, bzw. "kurz" davor ist es eh egal...

Weit davor haben wir hoffentlich andere Systeme besiedelt und die wichtigen Daten auf einem Holowürfel mitgenommen ;)
[/OT]

[shmia]

Wenn man anstelle eines AUTO-INC Feldes ein normales (Int-)Feld verwendet, dann stellt sich das Problem doch gar nicht, da man den Schlüsselwert selbst vergibt.
Beim Import zählt man einfach beginnend mit 1 nach oben.

Vorrausgesetzt man braucht die alten Daten nicht und löscht diese z.B. mit TRUNCATE TABLE.

[Piro]

Vielen vielen Dank an alle. Dank der guten Diskussion habe ich vieles gelernt.

Ich werde jetzt folgendes machen.

1. vorhandene Daten mit "TRUNCATE" löschen
2. Daten neu speichern
3. ID selber vergeben

Danke noch mal an alle. Tolles Forum.