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

[Piro]

Moin zusammen,

ich habe eine CSV Datei, die täglich erstellt wird und rund 100.000 Zeilen hat. Ich möchte die Daten in eine MS SQL DB schreiben, um Sie später besser zu verarbeiten.

Meine erste Idee war, immer die vorhandene Daten in der DB löschen und dann die neuen Daten in der DB schreiben. Das hat aber zur Folge, dass sich mein Primärschlüssel rapide erhöht und schnell an seine Grenzen stößt und überläuft.

Meine zweite Idee war, jeden Datensatz aus der Datei mit den Daten aus der DB zu vergleichen und ggf. ein Update oder Insert durchzuführen und das aktuelle Datum mit zu speichern. Nach dem Einlesen wird dann kontrolliert, welche Datensätze in der DB kein aktuelles Datum hat und wird gelöscht.

Ich tendiere zur 2. Idee. Leider sind die Kriterien für ein Update oder ein Insert nicht immer genau definiert. Es gibt keine eindeutige Identifikation.

Habt Ihr eventuell noch andere Idee, wie man am geschicktesten die Daten in die DB bekommt?

Vielen Dank im Voraus.

Sven

[fkerber]

Hi,

verstehe ich richtig, dass du die DB quasi jeden Tag komplett leerst und dann erst die Daten neu einfügst?


Edit: Was ist der primärschlüssel - einfach eine künstliche ID?

LG, Frederic

[Piro]

Das war meine erste Idee, die mir so spontan einfiel.

Ja, ich wollte erst alle Daten löschen und dann die neuen Daten speichern.

Der Primärschlüssel ist der eindeutige Index des Datensatzes, der hochgezählt wird. Gibt es in jeder DB in jeder Tabelle, um zwischen 2 Tabellen zu referenzieren.

Gruß

[fkerber]

Hi,

wenn ich dein Problem richtig verstehe (ID wird zu groß für den Wertebereich), dann könntest du nach dem Löschen doch einfach den Value wieder auf 1 setzen.

Für mySQL wäre das die Syntax:
ALTER TABLE 'tablename' AUTO_INCREMENT =1
LG, Frederic

[s.h.a.r.k]

Mal ganz blöd gefragt: Was für einen Typ hast du denn für den Primärschlüssel, dass der sehr schnell explodieren sollte? Nehme ich allein mal den Delphi Integer (und hier nicht mal unsigned) dann hast du circa 21474 Tag Zeit. Reicht dir das nicht? Dann nimm einfach unsigned int, dann hast immer das doppelte. Und in Datenbanken gibts mit Sicherheit auch ein Pendant zu Int64. Also Löschen brauchst du rein gar nichts.

Und DBMS sind zudem dafür ausgelegt eine derart große Anzahl an Daten zu halten, zumal du ja kein MySQL oder SQLite hast. MS SQL ist ein ausgewachsenes SQL-System.

[Assarbad]

Nimm doch SQLite. Dann haste sogar noch bessere Kontrolle und kannst die Dateien "wegschmeißen" (i.e. löschen) wenn nötig. Alternativ kann man sie auch sichern usw ...

Eine bessere Alternative zu CSV ist es allemal und damit haste deinen Code gleich zukunftssicher falls X-Plattform mal ein Problem werden sollte

Manko: auf eine SQLite-DB kann nur als Datei zugegriffen werden (nunja, zumindest ohne größere Änderungen), was auch bedeutet, daß es nur einen schreibenden Client geben kann.

[BUG]

Aber es ist schon etwas komisch das die ID überläuft, oder?
Selbst bei 100.000 neuen Einträgen pro Tag sollte es um die 100 Jahre dauern, bis ein 32bit-Ganzzahlwert überläuft.

[mkinzler]

Und wenn man einen BIGINT nimmt, hat man noch länger Ruhe.

[s.h.a.r.k]

mkinzler: Wie lange hast du denn vor zu leben!?

[Piro]

Danke für die Erklärungen. War dann wohl etwas ängstlich mit meiner ID. Will nur sicherstellen, dass es auch noch nach mir läuft.

Ich bin nur kein Freund von Daten rein -> raus -> rein -> und so weiter.

Ich glaube, ich werde meine 2 Idee umsetzen. Neue Daten aktualisieren bestehende Daten und nicht aktuelle Daten werden gelöscht. Das sollte das Beste sein, oder?

Mich würde mal interessieren, welche Logik ihr so verwendet für solche Aufgaben.

Vielen Dank im Voraus für die guten Antworten.