Reihenfolge des Eintragens in Tabelle ohne PK

[omata]

@mkinzler: Das habe ich auch so gemeint. Und das ist schlecht. Warum Leerzeichen abspeichern, die man dann wieder mit trim entfernen muss! Und warum die Datenbank künstlich aufblähen? Für Daten immer VARCHAR, nirmals CHAR verwenden. CHAR bietet sich für Schlüssel an (wenn diese mal nicht nummerisch sein können).

[mkinzler]

U.U. belegt ein Varchar aber sogar mehr.
http://ibexpert.net/ibe/index.php?n=Doc.CHAR

Am Besten ist ein Textblob, dort wird nur der wirklich benötigte Platz belegt und bei neueren Firebirdversionen kann man auf einen Textblob der weniger als 32K belegt auch äquivalent zu CHAR/VARCHAR zugreifen

[omata]

Ok, Firebird arbeitet da also anders. Ich bin vom Standard ausgegangen. Oracle, MSSQL und MySQL machen das anders. Also gelten die normalen Regeln für Datenbanken, in diesem Fall, bei Firebird nicht.

Entschuldigung für meine sinnlosen Beiträge.

[tsteinmaurer]

Das mit CHAR/VARCHAR und vollständige Speicherung stimmt überhaupt nicht. Im Gegenteil, die interne RLE Komprimierung macht das Ganze nochmals kleiner. Es hat noch zu InterBase 6 bzw. AFAIK Firebird 1.0 Zeiten das Problem gegeben, dass ein CHAR/VARCHAR in voller Länge übers Netzwerk ging, aber das ist lange her. Und die 2 Bytes, die ein VARCHAR mehr braucht als CHAR ist rein darin begründet, dass man sich irgendwo die Länge des VARCHARs ablegen muss, darum ist die max. Länge eines VARCHARs auch 32765 und eines CHARs 32767.

[omata]

@tsteinmaurer: Ich habe überhaupt nicht über das Netzwerk gesprochen! Aber wie auch immer, Firebird handhabt das also anders als andere Datenbanken.

@Valle: Meine Güte, wo steht die Goldwage? So genau wollte ich nun doch gar nicht sein. Es ging ums Grundsätzliche (und meine Aussage gilt auch bei allen anderen Datenbanken (wobei "alle" natürlich jetzt wieder ein Angriffspunkt ist))

[tsteinmaurer]

@omata: Hatte auch Markus gegolten, dass das mit der Speicherung Quatsch ist.
@Valentin: Darum legt Firebird bei einem VARCHAR in den ersten beiden Bytes auch die Länge des tatsächlichen Strings ab.

[hoika]

Hallo,

um mal wieder zu meiner Frage zurückzukommen ...


Heiko