MS-Office-Forum

Zurück   MS-Office-Forum > Microsoft Access & Datenbanken > Microsoft Access
Registrieren Forum Hilfe Alle Foren als gelesen markieren

Banner und Co.

Antworten
Ads
Themen-Optionen Ansicht
Alt 16.01.2003, 21:15   #1
StehtimSchilf
MOF Profi
MOF Profi
Standard Grösste (bytemässig) Tabelle ermitteln

Um unserer riesigen Daten (wirklich nur DATEN)-Bank entgegenzutreten, wollen wir die DB jetzt aufsplitten! (Bringt das performancemässig überhaupt was?)

Da die DB gewisse "Tabellen-Gruppen" besitzt, möchten wir nun ermitteln, welche "Gruppe" am meisten Platz beansprucht!

Wie kann ich nun einfach ermitteln welche Tab wieviel Platz beansprucht?

Logo - die Tabs wachsen, manche schneller, manche gar nicht...

Ich hab mir so was überleg:
für jedes Feld der Tab, ermittle Datentyp, anhand des Datentyps weiss ich ja wieviel Platz der beansprucht, dann das Resultat * Anzahl Records!

So als Richtwert

Ich weiss ja, welche Tabs schnell wachsen und welche nicht nur ist es schwer abzuschätzen was wilder ist: 40Felder*50'000 Records oder 10Felder x 500'000 Records!


angeri schlafe um diä Zyt
StehtimSchilf ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 16.01.2003, 22:41   #2
Sascha Trowitzsch
MOF Guru
MOF Guru
Standard

Für die Datentypen steht irgendwo in der Hilfe, wieviel Bytes sie belegen.
Beim Datentyp Text und Memo kann man das aber nicht sagen, weil sie variabel sind. Für diese müsstest du einen VBA-Code durchlaufen lassen (alle Tabellen, alle Stringfelder) und jeweils Len(String) aufaddieren.
Es ist dabei wahrscheinlich nicht nötig, das für alle Datensätze zu machen. Eine Stichprobe von sagen wir 3000 DS dürfte schon statistisch ausreichend genau sein, um die jeweilige durchschnittliche Stringlänge zu ermitteln.
Die dann multipliziert mit RecordCount.

Aber: Aus Performancegründen in einzelne Backends aufzusplitten ist kontraproduktiv. Es wird langsamer. Das ist Meinung in comp.databases.msaccess und auch Ergebnis eigener Tests.

Ciao, Sascha
Sascha Trowitzsch ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 20.01.2003, 11:51   #3
StehtimSchilf
Threadstarter Threadstarter
MOF Profi
MOF Profi
Standard

Danke für den Hinweis, dass dies kontraprokuktiv ist )))))
StehtimSchilf ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 20.01.2003, 12:12   #4
kama
MOF Guru
MOF Guru
Standard

Hallo
Nach meiner Erfahrung ist die Größe einer Datenbank (solange sie in den spezifizierten Grenzen bleibt) unerheblich. Interesant wird es nur wenn ich auf die Daten zugreifen will. Hier hilft eine Arichivierung nicht mehr benötigt Daten und eine Überprüfung der verwendeten Datentypen und Datenfeldgrößen.

Also würde ich nunächst mal überprüfen was steht denn drinn in meinen Tabellen. Ist für das Feld der richtige datentyp gewählt. z.B. Double oder Decimal wo Integer (Kleiner sollte es nicht sein) oder Single ausreichend seien würde. Ist die Länge der Textfelder angemessen? wenn nur ein Zeichen drinsteht und Feldlänge auf 255 gestellt ist wird (bin mir da aber nicht sicher) pro Zeichen 4 Byte gebraucht. ´Das heißt pro feld!!! 1 KB.
Und zuletzt ist die DB normalisiert? (Keine Redunanz)

Ich hofe das hilft dir etwas weiter.

__________________

kama
Take it easy und schlaf mal drüber.
kama ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 20.01.2003, 13:13   #5
Sascha Trowitzsch
MOF Guru
MOF Guru
Standard

@kama:

Ne, da hast du was durcheinander gebracht.
Zunächst mal braucht ein Zeichen eines Textfeldes 1 Byte in A97 und 2 Bytes in A2000/XP. Wenn in letzterem aber Unicode-Kompression eingeschaltet ist, so reduziert sich das in etwa auf die Hälfte.
Bei Memofeldern nützt die Unicode-Kompression erst bei Textlängen ab 2000. Davor wird in eine 4kb-Seite gespeichert, wenn ich mich recht erinnere.

Die Anzahl der Bytes, die ein Textfeld belegt, ist zum Glück nicht von der "Feldgröße" abhängig (im Unterschied zu z.B. dBase). Das ist im Tabellenentwurf etwas missverständlich. Die Feldgröße gibt bloß ein Limit der eingebbaren Zeichen an. Gespeichert wird aber nicht mehr, als eingegeben. Es wird nicht etwa mit Nullen aufgefüllt.

Ciao, Sascha
Sascha Trowitzsch ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 20.01.2003, 13:58   #6
kama
MOF Guru
MOF Guru
Top

@Sascha
Danke für die informationen

__________________

kama
Take it easy und schlaf mal drüber.
kama ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Ads
Antworten


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Besucher: 1)
 
Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge anzufügen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

vB Code ist An.
Smileys sind An.
[IMG] Code ist An.
HTML-Code ist An.
Gehe zu


Alle Zeitangaben in WEZ +1. Es ist jetzt 14:50 Uhr.



Powered by: vBulletin Version 3.6.2 (Deutsch)
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.

Copyright ©2000-2018 MS-Office-Forum. Alle Rechte vorbehalten.
Copyright ©Design: Manuela Kulpa ©Rechte: Günter Kramer
Eine Verwendung der Inhalte in anderen Publikationen, auch auszugsweise,
ist ohne ausdrückliche Zustimmung der Autoren nicht gestattet.