Grundsatzfrage: Definition von Foreign Keys

Parkside

Parkside

Benutzer
Beiträge
20
Ich habe ein grundsätzliche Frage zu Foreign Keys. Leider paßt sie in kein anderes Forum, glaube ich, denn adressiert ist sie an alle Benutzer von relationalen Datenbanken, egal von welchem Hersteller oder Entwicklerteam.

In MariaDB hatte ich einen FK definiert, der eine unique Spalte referenziert hat. In der Referenztabelle war der PK auf einer anderen Spalte. Dann habe ich die Tabellen migriert nach PG, und konnte den FK so nicht wiederherstellen. Es scheint, daß PG sich an eine strikte Definition hält:

Ein FK zeigt immer auf den PK einer anderen Tabelle.

Und das schließt aus, einfach einen unique-Key zu adressieren.

Microsoft sieht das so wie die MariaDB-Entwickler: Ein FK kann auch eine unique-Spalte referenzieren, andere Autoren schließen das kategorisch aus.

Wie seht Ihr das? An welcher SQL-Definition orientiert Ihr Euch?

Was mein praktisches Problem angeht: Ich habe PK und Unique-Index einfach vertauscht, damit hat's dann wieder gepaßt. Hoffentlich gibt es keine Seiteneffekte 😁 ...
 
Werbung:
Parkside schrieb:
Ein FK zeigt immer auf den PK einer anderen Tabelle.
Zum Vergrößern anklicken....
Nein, ein FK kann auch auf Spalten mit einem unique constraint (oder index) zeigen.

Das folgende funktioniert:

Code: 
create table t1
(
  id integer primary key, 
  code text unique
);

create table t2
(
  id integer primary key,
  some_data text,
  t1_code text references t1(code)
);
 
Parkside schrieb:
Ein FK zeigt immer auf den PK einer anderen Tabelle.

Und das schließt aus, einfach einen unique-Key zu adressieren.
Zum Vergrößern anklicken....

das stimmt nicht ganz, man kann auch auf einen unique-wert referenzieren.

Code: 
create table tableeins(name text unique);
create table tablezwei(name text references tableeins(name));
insert into tableeins(name) values ('Alf');

/*
insert into tablezwei(name) values ('Raimund');
ERROR:  insert or update on table "tablezwei" violates foreign key constraint "tablezwei_name_fkey"
Key (name)=(Raimund) is not present in table "tableeins".
*/

insert into tablezwei(name) values ('Alf');
INSERT 0 1

LG Baerlie ;)

edit:
:( er war schneller :(
 
Okay, danke an Euch beide, egal ob schnell oder einen Tick weniger schnell 😉

Ich habe versucht, den FK auf die unique-Spalte in DBeaver zu setzen. Es wundert mich, daß er das unter MariaDB zugelassen hat, sich unter PG aber geweigert hat. Ich muß das in psql mal durchspielen.
 
Also, man lernt nie aus: Ich habe im DBeaver-Dialog übersehen, daß man dort den Typ der referenzierten Spalte ändern kann, in meinem Fall muß, nämlich von PK auf Unique. Uff. Wieder nicht genau genug hingeschaut.
 
castorp schrieb:
Hmm, ich bin ja kein Fan von GUIs um Tabellen oder andere DB Strukturen anzulegen. Man lernt viel besser (und nachhaltiger), wenn man das SQL auch selber schreibt.
Zum Vergrößern anklicken....
Ob Du's glaubst, oder nicht, ich bin Deiner Meinung! Aber manchmal auch faul. Ich weiß, das ist nicht gut. ABER: Als DBeaver keine Probleme hatte, einen Tabelleninhalt umzukopieren, habe ich mich gefragt, warum mein anfänglich (!) erstelltes SQL-Statement ein Problem damit hatte. Und daraufhin habe ich herausgefunden, daß
Code: 
insert into new_table
select dies,das,jenes
from old_table;
gerne in die Hose gehen kann, wenn man in der Zieltabelle eine physisch andere Spaltenabfolge hat. Und es viel besser ist, grundsätzlich, denke ich, das so zu machen:
Code: 
insert into new_table (dies,das,jenes)
select dies,das,jenes
from old_table;
Ich bemühe mich also, die Augen offenzuhalten 😉 ! Trotzdem, Dein Hinweis ist mehr als berechtigt (falls es sowas gibt).
 
Meine Empfehlung ist es bei INSERT die Zielspalten immer explizit zu erwähnen. Egal ob die Quelle ein Abfrage oder einfach nur eine VALUES Liste ist.

Es gibt einen Spruch "You live by the GUI, you die by the GUI". Was so viel bedeutet: "Wer sich auf eine GUI verlässt, hat verloren"
 
Okay, klar, man kann nicht hinter die Kulissen schauen, wenn man das Ding nicht selber geschrieben hat.
Dann vollziehe ich jetzt mit dem Wechsel auf PG auch einen Wechsel von DBeaver auf psql.
Einverstanden 😇 ? Ich mein's ernst!
 
Parkside schrieb:
Dann vollziehe ich jetzt mit dem Wechsel auf PG auch einen Wechsel von DBeaver auf psql.
Zum Vergrößern anklicken....
Soweit musst Du ja nicht gehen 😄
Du kannst in DBeaver ja auch SQL direkt ausführen. Ich habe mein SQL gerne in einem vernünftige Editor. Die Kommandozeile ist für mich mehr ein Hilfsmittel zu Automatisierung (oder wenn ich ohne GUI auf einem Server arbeiten muss)
 
Werbung:
Zurück
Oben