Firebird DB Datensatz über RDB$DB_KEY finden

[Kostas]

Hallo Zusammen,

IBExpert zeigt RDB$DB_KEY den Wert '129:27' an.
Wie müsste ich den value convertieren so dass ich danach über Where suchen kann?

das habe ich versucht

Code:

where DB_KEY = cast('129:27' as char(8));
where RDB$DB_KEY = '129:27'

[IBExpert]

ist aus meiner sicht keine gute idee, weil du ggf nach einem backup/restore die datensätze unter anderen werten wieder finden würdest

cast(RDB$DB_KEY as CHAR(8) CHARACTER SET OCTETS)

zeigt dir den wert aber in anderer art an, aber zum speichern oder suchen bringt dich das nicht weiter

[Kostas]

Oh, danke für den Hinweis. Das wusste ich nicht, somit hat sich das erledigt.

[knuut21]

Falls Du in diese Richtung dennoch weiter denken möchtest, hier ein schönes Anwendungsbeispiel: https://www.ibphoenix.com/resources/...how_to/doc_385

[stalkingwolf]

die DB_KEY kommen nur dann rein, wenn ihr keinen Primary Index definiert habt.
IMO sind die Tabellen auch nur für kleine Datenmengen zu gebrauchen. Weil die Performance beim Insert ist alles andere als gut.

[Lemmy]

Zitat:

Zitat von stalkingwolf (Beitrag 1502617)

die DB_KEY kommen nur dann rein, wenn ihr keinen Primary Index definiert habt.

nein, den kannst du auch bei Tabellen abfragen die einen PK haben.

Zitat:

Zitat von stalkingwolf (Beitrag 1502617)

IMO sind die Tabellen auch nur für kleine Datenmengen zu gebrauchen. Weil die Performance beim Insert ist alles andere als gut.

Was willst Du damit sagen? Welche Tabellen? die von Firebird?

[IBExpert]

vielleicht zum verständnis:

jede tabelle hat für jeden datensatz einen wert für rdb$db_key, der ist immer binär eindeutig
pro Datensatz und ist zB für die Indizes erforderlich. In einem Index befindet sich zB ein
Wert und dazu dann die liste der rdb$db_key werte, die zu diesem Wert in den Records zu
finden sind

das was ibexpert und andere tools da als Darstellung benutzen entspricht dem Inhalt,
vor dem Doppelpunkt ist eine konstante pro Tabelle (ist im Prinzip die RDB$RELATION_ID
in RDB$RELATIONS). Wenn da zb 129 steht ist die Tabelle dort mit der ID 129 gespeichert.

wenn Ihr eine tabelle habt mit zB char(1) a..z also 26 records, die nacheinander
in der reihenfolge per insert eingefügt werden, dann sieht das so aus als ob dahinter
dann 129:1, 129:2, ... 129:26 steht, was binär auch stimmt.

wenn ihr nun b..y löscht bleiben als sichtbare rdb$db_keys nur
129:1=a und 129:26=z übrig

und nach einem backup/restore werden die nun nur noch 2 records mit neuen rdb$db_keys
eingespielt
129:1=a und 129:2=z

nach dem restore werden auch die indizes neu erstell, haben also dann auch die richtigen
Werte

Für eine technische Anwendung ist außerhalb der internen Verwaltung, die Firebird damit macht,
die Nutzung vom rdb$db_key eine ziemlich unbrauchbare idee

Im Prinzip ist das sozusagen nichts anderes als die interne hausnummer jedes Records
die nur bis zum restore statisch ist

[IBExpert]

Zitat:

Zitat von stalkingwolf (Beitrag 1502617)

die DB_KEY kommen nur dann rein, wenn ihr keinen Primary Index definiert habt.
IMO sind die Tabellen auch nur für kleine Datenmengen zu gebrauchen. Weil die Performance beim Insert ist alles andere als gut.

da fehlt mir auch jeder technische zusammenhang in dieser Aussage
warum "sind die Tabellen auch nur mit kleinen Datenmengen zu gebrauchen"?

Was mache ich falsch, das bei mir Inserts auf Tabellen mit mehr als einer
Milliarde Datensätze schnell laufen? ist das noch eine kleine Datenmenge?

[stalkingwolf]

Vergesst es. Bei uns wird der RDB$DB_KEY in 2 Tabellen per Default in FlameRobin angezeigt, weil diese beiden Tabellen keinen PK besitzen. Daher auch der Bezug auf die Performance.