Firebird Blob Sub_type text kein primary key möglich?

[Monday]

Hallo,

ich lerne mich in Datenbanken ein.

Bei Firebird 4 will ich eine Tabelle anlegen.

Auf ein Feld mit dem Datentyp "blob sub_type text" bzw. "blob sub_type 1" ist es nicht möglich ein Primary key oder unique anzulegen. Habe ich das richtig verstanden? Bei anderen Typen funktioniert es wohl.


Das funktioniert:

Delphi-Quellcode:

create table tabelle (
  a VARCHAR(100)  primary key
);

Delphi-Quellcode:

create table tabelle (
  a int not null,
  primary key (a)
);

Das funktioniert nicht:

Delphi-Quellcode:

create table tabelle (
  a blob sub_type text  primary key
);

Delphi-Quellcode:

create table tabelle5 (
  a BLOB SUB_TYPE text not null,
  primary key (a)
);

Nur für mein Verständnis.

Ich weiß nicht, warum das nicht funktioniert und ob das so vorgesehen ist oder ein Fehler meinerseits.


Wenn ich einen längeren Text speichern wollte, und nicht blob sub_type text geht wegen primary key, welcher Datentyp ist dann der geeignete?!

[Uwe Raabe]

Das ist vermutlich in allen Datenbanken so. Blob-Felder werden meistens in separaten Bereichen gespeichert und stehen für die Indizierung nicht zur Verfügung (uns somit insbesondere auch nicht für den Primary Key).

Steht übrigens auch in der Doku: http://www.firebirdsql.org/file/docu...0-ddl-index-de

Zitat:

Spalten der Typen BLOB und ARRAY sowie berechnete Felder können nicht in einem Index verwendet werden

[himitsu]

Das not-null ist doppelt gemoppelt,
weil

SQL-Code:

primary key

ist quasi ein shortcut für

SQL-Code:

not null unique

.

Ich schätze mal der Unique-Index wird den BLOB nicht mögen.

[haentschman]

Zitat:

Auf ein Feld mit dem Datentyp "blob sub_type text" bzw. "blob sub_type 1" ist es nicht möglich ein Primary key oder unique anzulegen.

...auch wenn du am Ausprobieren bist...ein Primary Key ist (sollte :zwinker:) immer eine Zahl sein...weil eindeutig pro Tabelle, besser Datenbank global über den Generator des Firebird. Der Feldname des Keys sollte irgendetwas mit *ID* sein. Texte als eindeutigen Key anzulegen ist *bäääh* ... auch wenn es möglich ist. :zwinker:

:wink:

[Monday]

Ok, Danke :)

[DeddyH]

Zitat:

Zitat von haentschman (Beitrag 1508423)

Texte als eindeutigen Key anzulegen ist *bäääh* ... auch wenn es möglich ist. :zwinker:

Das ist in dem Moment nicht mehr *bäääh*, wo man Daten serverübergreifend abgleichen soll/muss (damit meine ich keine Replikation).

[himitsu]

Jupp, wolle ich auch grade anmerken.

Zumindestens AUTOINC ist da eher unpraktisch.

Man könnte aber stattdessen einen TIMESTAMP (current_timestamp) verwenden, das ist zemlich unterschiedlich, da es hoffentlich nicht oft vorkommt, dass INSERT in zwei DBs auf die Millisekunde gleichzeitig passiert.
Oder im VARCHAR z.B. TimeStamp+Loginname.

[haentschman]

Ok, ok...ich hatte ne schwere Kindheit. :stupid:

Man könnte auch eine GUID (eindeutig weltweit) verwenden. Ist ja im "Prinzip" darstellungstechnisch auch ein "Text". :oops:

Zitat:

wo man Daten serverübergreifend abgleichen soll

...wir reden über die ersten Schritte des TE. Aber Recht hast du trotzdem...:zwinker:

[Uwe Raabe]

UUIDs sind auch eine Alternative, wenn man ein paar Dinge beachtet: https://tomharrisonjr.com/uuid-or-gu...l-7b2aa3dcb439

[himitsu]

Man kann auch die GUID/UUID als ID nutzen, auch für Syncro,
und zusätzlich noch einen INT/BIGINT für die Lokalen Verknüfungen.

In der Syncro nutzen wir eine TimeStamp/GUID
aber intern wird mit INT oder BIGINT (aber als VARCHAR(32) gespeichert) verlinkt.

Werden abhängige Tabellen Syncronisiert, muß man dann die internen und externen IDs umrechnen.

bzw. bei einigen (älteren) Tabellen, die früher nur über den INT (AUTOINC) verlinkt und syncronisiert wurden,
hatte ich die Syncro zuletzt so umgestellt, dass ein/mehrere andere Spalten als eindeutige "SyncID" genommen werden und der INT nur intern verbleibt (auf allen Datenbanken unterschiedlich).

[IBExpert]

Zitat:

Zitat von himitsu (Beitrag 1508470)

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) :angle:

[IBExpert]

Zitat:

Zitat von himitsu (Beitrag 1508486)

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?

SQL-Code:

VARCHAR(65000)

:stupid:

[edit]
OK, dann eben nur

SQL-Code:

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. :lol:

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