2
MS Access - Feldgröße wichtig?
Liebe Mitglieder,
ein Bekannter von mir behauptet, dass die Feldgröße der Felder in Access Datenbanken keinen Einfluss auf die Performance haben. Ich bin der Meinung, dass Access, wenn ich die Feldgröße für ein Textfeld auf 255 Zeichen stelle, auch soviel Speicher reservieren muss. Mein Bekannter sagt, Access speichert die Feldwerte dynamisch und daher macht es absolut keinen Performanceunterschied, ob man nun mit 50 Zeichen geizt oder einfach 255 Zeichen einräumt.
Hat jemand vielleicht technische Hintergrundinformationen?
Viele Grüße
Christoph
ein Bekannter von mir behauptet, dass die Feldgröße der Felder in Access Datenbanken keinen Einfluss auf die Performance haben. Ich bin der Meinung, dass Access, wenn ich die Feldgröße für ein Textfeld auf 255 Zeichen stelle, auch soviel Speicher reservieren muss. Mein Bekannter sagt, Access speichert die Feldwerte dynamisch und daher macht es absolut keinen Performanceunterschied, ob man nun mit 50 Zeichen geizt oder einfach 255 Zeichen einräumt.
Hat jemand vielleicht technische Hintergrundinformationen?
Viele Grüße
Christoph
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 37352
Url: https://administrator.de/contentid/37352
Ausgedruckt am: 23.11.2024 um 01:11 Uhr
2 Kommentare
Neuester Kommentar
Moin bvsn,
tja, wie soll ich sagen, ihr habt beide in gewisser Weise Recht und auch Unrecht.
Nicht ausdrücklich auf ACCESS bezogen dazu folgendes:
Richtig ist, dass VARCHAR(n)-Felder im Gegensatz zu CHAR(n) "nur" den Speicherplatz verbrauchen, der dem Inhalt entspricht.
Also 5 Byte, wenn Du den String "Hallo" in einem VARCHAR(255)-Feld speicherst.
Dazu kommt eine Offset/Pointer-Information, in der hinterlegt ist, wo denn tatsächlich dieser String "Hallo" gespeichert ist und wie lang er ist.
Nun der Pferdefuss.
Wenn Deine Datentabellen eine "normale" Änderungsfrequenz haben und irgendwann auch aus dem 5-Byte-String "Hallo" ein String "Tach, ich bin der Biber" wird, dann kann dieser String nicht mehr an/in demselben Speicherort untergebracht werden, in dem die 5-"Hallo"-Byte gespeichert wurden.
Der neue String wird anderswo gespeichert, der Zeiger auf den String aktualisiert und auf den String "Hallo" zeigt nichts mehr... dieser Bereich ist ungenutzt/tot/frei, je nach Sichtweise.
Denn es ist ja höchst unwahrscheinlich, das irgendein anderes VARCHAR-Feld irgendwann mal genau 5 Byte benötigt und diesen Freiraum verwenden kann.
Bei hoher Änderungshäufigkeit in VARCHAR-Feldern steigt also der verschwendete Speicherplatz durch "ehemalige" Feldinhalte, die Fragmentierung und der interner Verwaltungsaufwand für die ganze Verpointerung.
Auch (aber nicht nur) deshalb gibt es bei Datenbanken die Möglichkeit der "Reorganisation".
Meine Faustregeln (mit denen ich bisher gut gefahren bin) bei VarChar-Feldern:
- VARCHAR-Felder kleiner 50 sindBullshit ineffizient.
Unter 50 Zeichen Länge lieber CHAR-Felder mit fester Länge.
- wenn Varchar-Felder für Deine Applikation nötig/sinnvoll sind, diese immer an das Ende der Tabellenstruktur stellen. Denn ein Zugriff auf ein Feld, dass in der Reihenfolge NACH dem VARCHAR-Feld kommt, ist erst nach einer Längenberechnung des VarChar-Feldes möglich.
Gruß
Biber
tja, wie soll ich sagen, ihr habt beide in gewisser Weise Recht und auch Unrecht.
Nicht ausdrücklich auf ACCESS bezogen dazu folgendes:
Richtig ist, dass VARCHAR(n)-Felder im Gegensatz zu CHAR(n) "nur" den Speicherplatz verbrauchen, der dem Inhalt entspricht.
Also 5 Byte, wenn Du den String "Hallo" in einem VARCHAR(255)-Feld speicherst.
Dazu kommt eine Offset/Pointer-Information, in der hinterlegt ist, wo denn tatsächlich dieser String "Hallo" gespeichert ist und wie lang er ist.
Nun der Pferdefuss.
Wenn Deine Datentabellen eine "normale" Änderungsfrequenz haben und irgendwann auch aus dem 5-Byte-String "Hallo" ein String "Tach, ich bin der Biber" wird, dann kann dieser String nicht mehr an/in demselben Speicherort untergebracht werden, in dem die 5-"Hallo"-Byte gespeichert wurden.
Der neue String wird anderswo gespeichert, der Zeiger auf den String aktualisiert und auf den String "Hallo" zeigt nichts mehr... dieser Bereich ist ungenutzt/tot/frei, je nach Sichtweise.
Denn es ist ja höchst unwahrscheinlich, das irgendein anderes VARCHAR-Feld irgendwann mal genau 5 Byte benötigt und diesen Freiraum verwenden kann.
Bei hoher Änderungshäufigkeit in VARCHAR-Feldern steigt also der verschwendete Speicherplatz durch "ehemalige" Feldinhalte, die Fragmentierung und der interner Verwaltungsaufwand für die ganze Verpointerung.
Auch (aber nicht nur) deshalb gibt es bei Datenbanken die Möglichkeit der "Reorganisation".
Meine Faustregeln (mit denen ich bisher gut gefahren bin) bei VarChar-Feldern:
- VARCHAR-Felder kleiner 50 sind
Unter 50 Zeichen Länge lieber CHAR-Felder mit fester Länge.
- wenn Varchar-Felder für Deine Applikation nötig/sinnvoll sind, diese immer an das Ende der Tabellenstruktur stellen. Denn ein Zugriff auf ein Feld, dass in der Reihenfolge NACH dem VARCHAR-Feld kommt, ist erst nach einer Längenberechnung des VarChar-Feldes möglich.
Gruß
Biber
Oh, ich habe eben erst gesehen, dass auf meine Frage doch noch geantwortet wurde. Habe scheinbar keine Benachrichtigung hierfür erhalten. Ich danke dir für deine sehr ausführliche Information und werde die Hinweise berücksichtigen.
Gruß
Christoph
Gruß
Christoph
