Firebird Blob Sub_type text kein primary key möglich?

[IBExpert]

Zitat von himitsu:

aber intern wird mit INT oder BIGINT (aber als VARCHAR(32) gespeichert) verlinkt

warum macht man das denn?

je nach charset machst du aus 8 byte für bigint (und auch für indizes)
dann 34 Byte (bei single byte charsets inkl 2 längenbytes) oder bis
zu 130 Byte (UTF8)

Mag bei anderen db server anders sein, wird aber garantiert langsamer
sein unter allen Aspekten als beim native bigint zu bleiben

bzgl Thread Thema: Blobs lassen sich aus gutem Grund niemals indizieren
Ich bevorzuge bigint als pk (und weil ich faul bin heisst das feld auch
immer nur ID und fk tabellenname_id

create table master
(id bigint not null primary key,
txt varchar(80));

create table detail
(id bigint not null primary key,
master_id bigint references master(id) on delete cascade,
txt varchar(80));

[himitsu]

Weil das cool ist und vor 20+x Jahren so gemacht wurde?

Nja, abgesehn von einem winzigen Fall, wo beim Dokumentimport der Datensatz noch keine ID hat (da steht dann 'DV' dort drin), welches dann aber "später" im AfterPost, bzw. Trigger zugewiesen (überschrieben) wird (könnte man bestimmt auch so umbauen, dass es früher geht, aber dafür werden Werte verwendet, die aus einem der gefühlt 2000 millionenzeiligen Before-/AfterInsterTrigger kommen, welche ja erst bekannt sind, wenn es in der Datenbank war)


Im Prinzip ist das Feld/PK an nahezu jeder Tabelle dran, mit einem globalen Generator, über alle Tabellen, also datenbank-weiter eindeutiger Key (BIGINT als String)

[IBExpert]

Zitat von himitsu:

Weil das cool ist und vor 20+x Jahren so gemacht wurde?

das zweite argument kann ich gelten lassen

[Monday]

group by
geht bei blobs auch nicht oder?! Zumindest habe ich bei meinen Tests unlogische Ergebnisse bekommen.


Wie speichert man den in Firebird Texte die mehr als 255 Zeichen bzw. KB (varchar) sind?! Lange Texte auf 255 Zeichen splitten?


Irgendwie habe ich das Gefühl, ich benötige einen Firebird Grundkurs. Gibt doch ein paar Unterschiede zu SQLite.

[himitsu]

Je länger die Texte, um so nutzloser wird doch GROUP BY,
weil dann die Gleichheit schnell gegen Unendlich Null geht?

VARCHAR(65000)

[edit]
OK, dann eben nur VARCHAR(32000)
Firebird varchar max length

Zitat:

oder bis zu 130 Byte (UTF8)

ich glaub nicht, dass dort ein Charset für diese/irgendeine Spalte explizit gesetzt wird, also dann wohl eher irgendwelches Unicode.

[IBExpert]

char/varchar(32765) ist das maximum bei single byte character sets, bei utf8 aber nur maximal char/varchar(8191)
wenn auf der db default character set eingestellt war, dann wird das für alle string felder genommen,
wenn da nicht explizit was anderes deklariert wird (kann man nämlich auch in einer Tabelle mischen wenn
man will).

Lange char/Varchar sind gleichzeitig gut und schlecht, weil wenn man zB 1024 Byte lange keys für encryption
speichern will geht das da drin super, wenn man aber extrem lange char/varchar felder auf verdacht deklariert
muss man wissen, das auf der datenbankadtei ein char/varchar(32765) schon mal minimum ca 500 Byte belegt,
auch wenn da nix drin steht. Wenn so was da in einer temp datei wegen sort ohne index oder group by
landet, dann stehen die werte da drin sogar in voller länger. sollte man nur wissen.

Blobs haben andere vor und nachteile, hatte ich mal in meinen stammtisch videos auf youtube ziemlich ausführlich erklärt.

Nachteile sind aber immer nicht wirklich problematisch und in fast allen Fällen flexibel umstellbar durch
Anpassungen am Datenmodell.

Group by und Order by macht auf blobs wirklich unsinn, weil das im Prinzip auf dem Blobpointer sortiert/gruppiert
und nicht auf den daten. Wenn erforderlich, dann kann man vor dem sortieren das feld mit cast evtl ergänzt mit
substring be bedarf als varchar umwandeln, um das sinnvoll zu sortieren. Sinnvolle Gründe, blobs zu sortieren
kenn ich aber eher nicht (außer Datenmodelle von vor 20+x Jahren)