Firebird Datenbankgröße

[hstreicher]

Firebird verwendet eine RLE Komprimierung mit einem Byte für die Länge, es ist also für den Speicherbedarf egal ob das Feld als
Varchar(10) oder Varchar(100) definiert wird, wenn es meist weniger sind wie 8 Char im Varchar

das Varchar hat ein Integer(?16Bit?) als Länge das Varchar(10) belegt also maximal 12 Byte (Single Byte Charset vorrausgesetzt)

Auf der anderen Seite hat ein CHAR Feld immer nur die angegebene Länge also Char(10) hat eine Länge von 10
wird aber mit Spaces gepadded

zu beachten ist hier natuerlich auch der definierte Zeichensatz

[IBExpert]

zum vor und nachteil von char oder varchar bei Firebird:

Beim Speichern braucht Firebird für ein varchar mit gleichem Inhalt 2 Byte mehr als wenn es in einem Char gleicher maximallänge gespeichert wäre. Darin speichert Firebird die Datenlänge. Bei x Millionen Records also schon ein Vorteil, wenn man den char nimmt, der braucht diese beiden Bytes nicht. Abgesehen von den beiden Längenbytes speichert Firebird Inhalte von char und varchar in gleicher Länge, d.h. nahezu immer die reinen benutzten bytes plus ein wenig Overhead (lange chars/varchars mal ausgenommen).

Leider kein Vorteil ohne Nachteil, denn während varchars im Netzwerk als reine Nutzdaten + overhead übertragen werden, werden chars mit Leerzeichen aufgefüllt, leider auch + overhead. Bei den Beispieldaten hier sind das mit 3 Records 20 Byte (188 zu 168 Byte) weniger, also ca. 10 % weniger netzwerktraffic, wenn man den varchar nimmt. Da das Netzwerk meistens wesentlich langsamer ist als der Zugriff auf die Festplatte bzw der bereits im Ram gecachten Daten, ist bei netzwerkintensiven Programmen meistens der varchar vorteilhaft, bei archivierten Daten, die selten abgefragt werden oder wirklich festen Längen aber manchmal eben auch der char.
Dann bringt es dann ggf. wesentlich mehr, die von dir beschriebenen Varianten der Messwerte über Nachschlagetabellen mit einem 4 Byte integer als Foreign Key zu verbinden, wenn man schon um jedes Byte kämpfen will.

Datenpaket mit varchar

Code:

 
CREATE TABLE T1 (
    ID   BIGINT NOT NULL,
    TXT  VARCHAR(20)
);

Daten

ID    TXT
1    ABC
2    ABCDEF
3    ABCDEFGHIJKLMNOP

SQL

select * from T1

Netzwerkprotokoll Ausschnitt mit tcpipexpert erstellt

## 12:06:16:597 Channel 2; DATA (Server -> Client): Length= 168
00 00 00 09 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 42 00 00 00 00 00 00 00 01 00 00 00 00     B            
00 00 00 01 00 00 00 00 00 00 00 03 41 42 43 00              ABC 
00 00 00 00 00 00 00 42 00 00 00 00 00 00 00 01         B        
00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 06                  
41 42 43 44 45 46 00 00 00 00 00 00 00 00 00 42  ABCDEF         B
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 03                  
00 00 00 00 00 00 00 10 41 42 43 44 45 46 47 48          ABCDEFGH
49 4A 4B 4C 4D 4E 4F 50 00 00 00 00 00 00 00 42  IJKLMNOP       B
00 00 00 64 00 00 00 00                             d

Datenpaket mit char

Code:

CREATE TABLE T2 (
    ID   BIGINT NOT NULL,
    TXT  CHAR(20)
);

ID   TXT
1   ABC
2   ABCDEF
3   ABCDEFGHIJKLMNOP

SQL

select * from T2

Netzwerkprotokoll Ausschnitt mit tcpipexpert erstellt

12:06:29:002 Channel 2; DATA (Server -> Client): Length= 188
00 00 00 09 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 42 00 00 00 00 00 00 00 01 00 00 00 00     B            
00 00 00 01 00 00 00 00 41 42 43 20 20 20 20 20          ABC     
20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 00                  
00 00 00 42 00 00 00 00 00 00 00 01 00 00 00 00     B            
00 00 00 02 00 00 00 00 41 42 43 44 45 46 20 20          ABCDEF  
20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 00                  
00 00 00 42 00 00 00 00 00 00 00 01 00 00 00 00     B            
00 00 00 03 00 00 00 00 41 42 43 44 45 46 47 48          ABCDEFGH
49 4A 4B 4C 4D 4E 4F 50 20 20 20 20 00 00 00 00  IJKLMNOP        
00 00 00 42 00 00 00 64 00 00 00 00                 B   d

[mkinzler]

Zitat:

Beim Speichern braucht Firebird für ein varchar mit gleichem Inhalt 2 Byte mehr als wenn es in einem Char gleicher maximallänge gespeichert wäre.

Da in diesem Fall die Maximallänge als absolutes Maxiumium zu sehen ist, und im Durchschnitt viel kürze Daten vorliegen, ist VARCHAR wohl die richtige Wahl.