Hallo liebe Community,

ich versuch es kurz und knapp zu formulieren:

Ich habe folgenden (bestehenden) Ablauf umzustellen auf eine MSSQL Datenbank:

Wir verwalten in unserer aktuellen Anwendung die Daten in *.DBC und *.DBF - Dateien. Diese befinden sich immer im Ordner "data". Am Ende jeden Jahres, wird das "Data" Verzeichnis kopiert in z.B: "Data2009". Daraufhin wird das aktuelle "data" Verzeichnis wieder geleert damit Quasi für das Jahr 2010 komplett neu erfasst werden kann.

Der Kunde hat in der Anwendung die Möglichkeit, zwischen den einzelnen Jahren zu wechseln. Somit kann er seine Daten aus den Vorjahren weiter einsehen, aber auch in einem gereinigtem Stand für das aktuelle Jahr arbeiten.

Nun möchte ich diese Anwendung umstellen auf MSSQL. Dort habe ich kein Dateisystem mehr, welches ich "mal eben" umkopieren kann in ein "data2010" - was ich mittlerweile auch nicht mehr für die beste Lösung halte.

Nun wollte ich euch fragen, was ihr für Sinnvoll haltet. Soll ich einfach bei jeder Tabelle eine extra Spalte "year" mitführen, in der ich das Jahr verwalte? Somit müsste ich nicht mehr aufwändigerweise alle Tabellen hin und her kopieren und keine gesonderten (im falle von MSSQL) Datenbankzugriffe führen.. Im Sinne von "select database data2010" o.ä.

Ich hoffe ihr könnt in etwa nachvollziehen, worum es mir geht. Oder vielleicht bildet ja jemand von euch ein ähnliches Verfahren ab und hat schon erfahrungen gesammelt?

Gruß,
reloop

Also eigentlich ist ja eine Datenbank dafür gemacht, beliebige Daten zu speichern und dann eine View auf bestimmte Daten zu erstellen. Wenn du ein Datum (oder einen Timestamp) für jeden Vorgang mitspeicherst, kannst du ganz einfach die Daten für ein bestimmtes Jahr abfragen. Dateien rumkopieren und die Datenbank jedes Jahr leeren ist wirklich unpraktisch.

Zitat

Nun wollte ich euch fragen, was ihr für Sinnvoll haltet. Soll ich einfach bei jeder Tabelle eine extra Spalte "year" mitführen, in der ich das Jahr verwalte?

Ja, oder eine Spalte mit dem Datum.

Der SQL-Server kann auch große Mengen an Daten schnell selektieren. Event. einen Index / Key auf das Datumsfeld setzen.

Grüße Bernd

Hallo,

wir haben bei uns auch eine ältere, auf *.DBF basierende ERP Software im Einsatz.
Seit über 2 Jahren entwickeln wir auf eine Lösung hin, die die alte Software ablösen kann.

Daher kann ich dich beruhigen und du kannst ein vielfaches der Datenmengen aus den DBF - Datenbanken im SQL Server ablegen ohne Performance Probleme zu haben.

Es gibt dann auch keine numierschen Überläufe mehr in dem Sinne wie bei DBF :)

Die Tablle versiehst du mit einem DateTime - Feld und Indizes. Dabei ist es keine "rushmore" Optimierung notwendig oder ein Index auf jedes Feld.


Einziges "Manko": Wenn ein Datensatz gelöscht wird, ist er erstmal auch gelöscht und nicht erst "markiert". Aber da kann man ja auch Lösungen für entwerfen.

Gruß,
Andreas

P.S.: Mit welcher Sprache ist die *.DBF - basierende Lösung entwickelt? Bei uns ist es Visual FoxPro 9

Hallo!

Weiteres Stichwort: Partionierung.
Man kann eine Datenbank logisch unterteilen, um bei größeren Datenmengen trotzdem schnelle Zugriffszeiten zu gewährleisten. Die Partitionierung erfolgt dann anhand einer Abfrage eines Feldes, um z.B. nach Jahr zu unterteilen.

Hallo,

danke für dieses super Feedback. Das hat mir wirklich weitergeholfen.

@fod:
Die Entwicklung fand bei uns mit Visual Foxpro 7 statt.

Noch eine abschließende Frage an die Allgemeinheit:

Bis zu wieviel Datensätze arbeitet MSSQL den Performant? Ich frage aus dem Grund, da einige der Buchungstabellen gerne mal 200.000 Datensätze pro Jahr erreichen.

Gruss,
reloop

Bei 200.000 Datensätze brauchst du dir keine Gedanken machen.
Das schöne ist auch. Die Leistung des SQL - Servers skaliert gut mit der verwendeten Hardware (Achtung: Nicht bei der Express - Version).

Wir haben Beispielsweise ein Rechungsarchiv und die Tabelle mit den dazugehörigen Artikel - Positionen hat (bei ~ 73 Feldern) an die 600.000 Datensätze und es gibt damit keine Probleme.

Zitat

200.000 Datensätze pro Jahr erreichen.

Nach 1000 Jahren würde ich mir Gedanken machen ;-)

Grüße Bernd

Alles klar.

Vielen Dank an alle, für die spitzen Hilfe!

Gruß,
reloop