Reihenfolge des Eintragens in Tabelle ohne PK

[hoika]

Hallo #,

ich habe eine Tabelle mit Namen (Name Char(100)).
Ich benötige jetzt die Reihenfolge, in der diese Namen in die Tabelle gekommen sind
(das mit den Namen ist nur ein Bsp.)
Geht das über den ominösen rdb$db_key ?

Die DB könnte auch per Restore wiederhergestellt worden sein.

Bekommt man das nachträglich noch hin ?

Danke


Heiko

[tsteinmaurer]

Nein, das bekommt man nicht hin. Nur wennst die Ausgangsmenge als Liste etc. vor dir hast, darum immer einen PK mit Generator befüllt. :-D

[mkinzler]

Sobald ein datensatz gelsöcht wurde, entsteht eine Lücke ( spaätestens beim nächsten Sweep). Diese wird dann wieder gefüllt.

[hoika]

Hallo,

hatte ich mir schon gedacht ;(


Heiko

[omata]

Zitat:

Zitat von hoika (Beitrag 1130282)

...Namen (Name Char(100))...

Wieso wird dort der Datentyp CHAR verwendet?

CHAR speichert immer die maximale Zeichenanzahl (Nicht vorhandene Zeichen werden mit Leerzeichen aufgefüllt).

Für Datenfelder verwendet man immer VARCHAR!

[mkinzler]

Auch bei VARCHAR wird die maximale Anzahl belegt

[omata]

Nein, wenn ich VARCHAR(100) definiere und ich nur ein Zeichen ablege, wird auch nur Speicher für das eine Zeichen benötigt. Bei CHAR(100) und ablegen von einem Zeichen werden 100 Zeichen abgespeichert.

[mkinzler]

Es wird nur die belegte Anzahl übertragen. In der DB wird aber die maximale Anzahl an Stellen belegt.

[Valle]

Zitat:

Zitat von omata (Beitrag 1130352)

Nein, wenn ich VARCHAR(100) definiere und ich nur ein Zeichen ablege, wird auch nur Speicher für das eine Zeichen benötigt. Bei CHAR(100) und ablegen von einem Zeichen werden 100 Zeichen abgespeichert.

Das kann gar nicht sein. Es muss mindestens mal mitgespeichert werden, wie lang der String ist!

Liebe Grüße,
Valentin

[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).

[omata]

Zitat:

Zitat von Valle (Beitrag 1130354)

Das kann gar nicht sein. Es muss mindestens mal mitgespeichert werden, wie lang der String ist!

Nein! Du bekommst beim Auslesen 100 Zeichen zurück.

[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. :-D 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.

[Valle]

Zitat:

Zitat von omata (Beitrag 1130356)

Zitat:

Zitat von Valle (Beitrag 1130354)

Das kann gar nicht sein. Es muss mindestens mal mitgespeichert werden, wie lang der String ist!

Nein! Du bekommst beim Auslesen 100 Zeichen zurück.

Mh, ich glaube wir reden aneinander vorbei. Was ich sagen wollte: Wenn man in ein VARCHAR(100) Feld nur ein Zeichen speichern würde, dann ist es technisch gar nicht möglich, dass nur ein Byte verwendet wird. Immerhin muss man ja wissen wann der String aufhört. Trägt aber nicht wirklich zum Thema bei...

Liebe Grüße,
Valentin

[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. :-D
@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

[omata]

Zitat:

Zitat von tsteinmaurer (Beitrag 1130283)

Nein, das bekommt man nicht hin.

Die Frage war doch schon beantwortet :gruebel: