Datensätze zwecks Performanzgewinn archivieren

[Doming]

Hallo,

ich bastle weiterhin an unseren DB-Sauriern herum, dabei nervt die ,,Schnelligkeit" ganz ordentlich. Gerade wenn mehrere im Netzwerk zu Gange sind, wartet man Minuten, was bei Alleinzugriff Sekunden dauert.

Ich habe viele Datensätze, die nie mehr angefasst werden (bis zu dem Zeitpunkt, nachdem man sie gelöscht hat)
Sie reichen über Jahre zurück (versendete Packstücke) und sind allenfalls interessant, wenn irgendwas nicht angekommen ist. Aber auch das reicht höchstens nur ein paar Monate zurück.

Da mir endgültiges löschen zuwider ist, war meine Idee, diese 45.000 Datensätze in eine eigens dafür erschaffte Tabelle zu schieben (tblFriedhof  ) und nur noch die DS in der aktiven Tabelle zu lassen, deren Abarbeitung X Monate zurückliegt (etwa 2000 Stück).
Dadurch ist die Performanz natürlich arg gestiegen, man muss nur sehen, dass keiner mehr nach den leeren Fremdschlüsseln sucht.

Oder gibt es eine andere Weise, wie man die DS in einer Tabelle so markiert, dass sie die Verarbeitungsgeschwindigkeit der DB nicht sonderlich herabsetzen?

_{weia, beim Schreiben merke ich schon, dass es gleiche Haue gibt...}

Gruß
 Doming

[MzKlMu]

Hallo,
47T (45+2) Datensätze sind eher eine Kleinigkeit für Access. Da hast Du ganz sicher einige Bremsen eingebaut. Oftmals fehlen sinnvolle Indexierungen. Und das Netzwerk spielt natürlich auch eine Rolle.
Ich würde daher erst mal da ansetzen.

[Knobbi38]

wenn mehrere im Netzwerk zu Gange sind, wartet man Minuten, was bei Alleinzugriff Sekunden dauert

Bei alleinigem Zugriff wird auch dasselbe Backend übers Netz verwendet?

Multiuserzugriffe muß man natürlich beachten und bei der Programmierung sollte man immer nur soviel Daten lesen, wie unbedingt notwendig. Normalerweise wird ja eigentlich immer nur eine Übersicht geladen und dann selektiv ein DS bearbeitet. Da ist es eher unwahrscheinlich, daß mehrere Benutzer gleichzeitig auf denselben DS im Editmodus zugreifen wollen.

Einfach mal schauen, wo soviel Zeit verbraten wird und die Netzwerkbelastung möglichst minimieren.

Gruß Knobbi38

[Doming]

Wie heißt es so schön: never touch a running system...

Mein Vorgänger hat sich richtig Mühe gegeben und über manches habe ich schon den Kopf geschüttelt (redundante Daten). Aber häufig weiß ich nicht, wo welche Daten wie verändert werden und zu viel Energie will ich in das Verstehen auch nicht stecken, denn dann könnte ich auch gleich alles neu schreiben, was vermutlich schneller gehen würde.

[PhilS]

[...] dann könnte ich auch gleich alles neu schreiben, was vermutlich schneller gehen würde.

Das ist eine gängige Annahme, wenn Entwickler auf fremden Code stoßen, den sie nicht auf Anhieb verstehen.
In >> 75% der Fälle ist diese Annahme falsch.

[markusxy]

Oder gibt es eine andere Weise

Nicht vergessen, dass Access kein DBMS hat. Da muss der Klient also mitunter umengen an Daten laden um zum Ergebnis zu kommen. Kann auch die ganze Tabelle mehrfach anfordern.

Idealerweise verwendet man für die Datenhaltung also ein aktives DBMS, dass nur das Ergebnis liefert.
Bei Access muss man um das zu erreichen mitunter einzelne Abfragen als View in der Datenbank speichern.

[Doming]

Bei Access muss man um das zu erreichen mitunter einzelne Abfragen als View in der Datenbank speichern.

Was heißt das? Lokale Tabellen? Wie speichere ein ,,view" (klingt mir nach SQL-Sprech)

Gruß
 Doming

[markusxy]

Was heißt das? Lokale Tabellen? Wie speichere ein ,,view" (klingt mir nach SQL-Sprech)

Na, ja in meiner Info geht es darum, einen SQL Server als Backend zu verwenden.
Damit erreichst du gegenüber Access als Backend je nach dem wie eine Abfrage aussieht eine miminale Netzwerklast.
Bei komplexen Abfragen, musst du diese dann entweder als View am SQL Server speichern und die View wie eine Tabelle verknüpfen, oder es wird statt odbc mit dao via oledb mit ado zugegriffen.
Da geht's also mehr um Fragen der Architektur.
ADO hat da natürlich auch seine Vor- und Nachteile.
Vor allem beim Verteilen von Lasten zwischen Server und Client bei allem ausser Reports recht nützlich und sollte man meiner Meinung nach schon kennen, wenn man mit Access arbeitet da du mit Access bei den Möglichkeiten im Vergleich zu sonstigen Entwicklungsumgebungen recht eingeschränkt bist.
Aber ADO ist insofern nur ein Nebenthema in der Sache.
Verstehen sollte man den Unterschied zwischen Access als Backend und einem SQL Server verstehen.
Das ist der erste und wichtigste Punkt, wenn es um MultiUser Anwendungen geht und gleichzeitig hat man dann ein Werkzeug für sinnvolle Abfragen im Vergleich zu Access, was ja wirklich ein Trauerspiel im Bereich SQL ist.

[Doming]

Moin Markus,

danke für die Ausführungen.
Da muss ich mal bei der IT anfragen, ob die mir sowas zur Verfügung stellen.

Gruß
 Doming