Firebird Blob Sub_type text kein primary key möglich?

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

[Monday]

Ok, Danke

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

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

Zitat:

wo man Daten serverübergreifend abgleichen soll

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

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

[DeddyH]

Zitat von haentschman:

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

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