Wie reduziere ich die wachsende Größe einer Zugriffsdatei?

Question

An meinem Arbeitsplatz haben sie also eine riesige Zugriffsdatei (verwendet mit MS Access 2003 und 2007). Die Dateigröße beträgt ca. 1,2 GB, daher dauert es eine Weile, die Datei zu öffnen. Wir können keine der Datensätze löschen, und wir haben über 100 Tabellen (jeden Monat erstellen wir noch 4 weitere Tabellen, fragen Sie nicht!). Wie verbessere ich das, dh die Datei verkleinert?

Answer 1

Nun .. Hören Sie @larry und denken Sie daran, dass Sie langfristig eine andere Datenbank finden müssen, um Ihre Daten zu halten!

Kurzfristig bin ich durch diese "4 neuen Tische pro Monat" ziemlich beunruhigt. 4 Tabellen pro Monat sind 50 pro Jahr ... das klingt sicherlich für jeden "Datenbankmanager" hier seltsam. Sagen Sie uns also bitte: Wie viele Zeilen, wie werden sie gebaut, wofür sind sie und warum müssen Sie jeden Monat Tische bauen?

Je nachdem, was Sie mit Ihren Daten tun, können Sie auch darüber nachdenken, einige Tabellen als XML -Dateien (oder sogar XLS?) Archivieren. Dies könnte für "historische" Daten sinnvoll sein, auf die nicht durch Beziehungen, Ansichten usw. zugegriffen werden muss. Ein gutes Beispiel wäre die von einem PABX gesammelte Telefonanrufliste. Daten können als/geladen von XML/XLS -Dateien über ADODB -Datensätze oder die TransferDatabase -Methode gespeichert werden

Answer 2

Sie können zwei Dinge tun:

• Verwenden Sie verknüpfte Tabellen
• "kompakt" die Datenbank (en) von Zeit zu Zeit

Die verknüpften Tabellen begrenzen nicht in sich die Gesamtgröße der Datenbank, sondern "verpackt" sie in kleineren, verwaltbaren Dateien. Um darauf zu schauen:

'File' menu + 'Get External data' + 'Linked tables'

Verbindete Tabellen haben auch viele Vorteile, z.

Kompaktierende Datenbanken können den Speicherplatz zurückgewinnen, ansonsten als verschiedene CRUD -Operationen (einfügen, löschen, aktualisieren), Fragmentieren Sie den Speicher. Es gruppieren auch Tabellen und Indizes neu, wodurch die Suche effizienter wird. Dies geschieht mit

  'Tools' menu + 'Database Utilities' + 'Compact and Repair Database...'

Answer 3

Sie drängen sich wirklich gegen die Grenzen des MS -Zugriffs dort - sind Sie sich bewusst, dass die Datei nicht größer als 2 GB wachsen kann?

Ich nehme an, Sie haben die Daten bereits für mögliche Speichersparen durch zusätzliche Normalisierung untersucht? Sie können einige der Tabellen für die vergangenen Monate in separate MDB -Dateien "archivieren" und diese dann (dauerhaft oder nach Bedarf) mit Ihrer "aktuellen" Datenbank verknüpfen (in diesem Fall würden Sie tatsächlich von einer wahrscheinlich ansonsten schlechten Entscheidung profitieren neue Tische für jeden Monat zu starten).

Mit dieser Datenmenge ist es jedoch wahrscheinlich an der Zeit, auf eine geräumigere Plattform zu planen.

Answer 4

Sie sollten wirklich über Ihre DB -Architektur nachdenken. Wenn es keine Links zwischen den Tabellen gibt, können Sie versuchen, einige davon in eine andere Datenbank zu verschieben (ein dB pro Jahr :) als kurzfristige Lösung.

Answer 5

Fügen Sie jeden Monat mehr Tabellen hinzu: Das ist bereits eine fragwürdige Einstellung und scheint in Bezug auf die Datennormalisierung misstrauisch zu sein.
Wenn Sie dies tun, vermute ich, dass Ihre Datenbankstruktur auch in Bezug auf Feldgrößen, Datentypen und Indizes suboptimal ist. Ich würde wirklich beginnen, diese zu überprüfen.

Wenn Sie wirklich eine Rechtfertigung für monatliche Tische haben (was ich mir wieder nicht vorstellen kann), warum nicht 1 Back-End pro Monat?
Sie könnten auch das Haupt-Back-End haben, sagen wir mit sagen wir uns 3 Monate lang online und dann eine Archiv-DB, in der Sie Ihre älteren Datensätze übertragen.
Ich benutze das für Transaktionen, wobei die Haupttabelle etwa 650.000 Datensätze aufweist und der Zugriff sehr reaktionsschnell ist.

Answer 6

Ein paar Ideen „Greifen über Strohhalme“

Schauen Sie sich die Datentypen für jede Spalte an. Möglicherweise können Sie einige Zahlen als Bytes speichern, die einen kleinen Betrag pro Datensatz sparen

Schauen Sie sich die Indizes an und entfernen Sie diejenigen, die Sie nicht verwenden. Auf großen Tabellen können unnötige Indizes eine große Menge Overhead hinzufügen.

Ich würde + 2^64 Die Vorschläge über das Datenbankdesign sind etwas seltsam, aber nichts, was noch nicht gesagt wurde, also werde ich den Punkt nicht arbeiten