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