PostgreSQL "REFERENCES"

Alles zum SQL-Dialekt

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

PostgreSQL "REFERENCES"

Beitrag von AUGE_OHR »

hi,

ich habe hier ein Beispiel mit 2 Table

Code: Alles auswählen

-- Table: country
-- DROP TABLE country;
CREATE TABLE country
(
  code integer NOT NULL,
  name character(35),
  CONSTRAINT "PK_Ct" PRIMARY KEY (code )
)
WITH (
  OIDS=FALSE
);
ALTER TABLE country
  OWNER TO postgres;
und

Code: Alles auswählen

-- Database: consumo
-- DROP DATABASE consumo;
CREATE DATABASE consumo
  WITH OWNER = postgres
       ENCODING = 'UTF8'
       TABLESPACE = pg_default
       LC_COLLATE = 'Spanish, Chile'
       LC_CTYPE = 'Spanish, Chile'
       CONNECTION LIMIT = -1;

-- Table: clients
-- DROP TABLE clients;
CREATE TABLE clients
(
  id integer NOT NULL,
  name character(35),
  lastname character(35),
  codect integer,
  CONSTRAINT "Ky_Cu" PRIMARY KEY (id ),
  CONSTRAINT "Fk_Ct" FOREIGN KEY (codect)
      REFERENCES country (code) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE SET NULL
)
WITH (
  OIDS=FALSE
);
ALTER TABLE clients
  OWNER TO postgres;
die erste Table "country" soll wohl "automatisch" in einer Combobox angezeigt werden.
Combo_Country.PNG
Combo_Country.PNG (62.98 KiB) 7855 mal betrachtet
und nun die Fragen :
a.) 2 x Table d.h. 2 x Connectionen für getrennte Result Sets, oder beide zusammen "aufmachen" ?
b.) mit / ohne Thread ?
c.) wie "verknüpfe" ich die beiden Table ?

ich "denke" das es mit dieser Zeile zu tun hat

Code: Alles auswählen

      REFERENCES country (code) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE SET NULL
aber ich werde nicht "schlau" daraus.

Code: Alles auswählen

      REFERENCES country (code) 
ok das kapiere ich wohl noch.
REFERENCES -> "Verweis"
country -> Table
(code) -> Parameter "was" er im PRIMARY KEY (code) suchen soll

... aber die "verwende" ich das ?

Code: Alles auswählen

      ON UPDATE CASCADE 
      ON DELETE SET NULL
sind das 2 Befehle oder gehört das alles zusammen ?
"ON UPDATE" und "ON DELETE" wären ja Events ... aber erst "nach" einer User Aktion
"CASCADE" find ich im Pg Handbuch nur mit "DELETE" oder "DROP" aber nicht mit "ON UPDATE" :banghead:
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "REFERENCES"

Beitrag von AUGE_OHR »

hi,

ich habe nun mal die "Country" Table mittels pgAdmin.EXE mit paar Einträgen versehen und nun sieht die Sache ganz anders aus ;)

die Combobox soll ja, beim navigieren, immer die richtige Nationalität anzeigen.
es ist also praktisch wie "SET RELATION TO Country_Table" unter Xbase.

mit "REFERENCES" wird anscheinend eine Aktion ausgelöst welches ein "aktuelles" (eindeutiges?) Result zurück gibt.
gruss by OHR
Jimmy
bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: PostgreSQL "REFERENCES"

Beitrag von bgl »

REFERENCES (kurzform von FOREIGN KEY (column_name) REFERENCES other_table [(column_name)] ) ist eine einschränkende Bedingung für die Tabellenspalte, welche sagt "DORT MUSS EIN KORRESPONDIERENDER EINTRAG VORHANDEN SEIN!"

Folgendes ist dabei zu beachten:
Darf das Feld, welches eingeschränkt ist, NULL beinhalten, so ist NULL "immun" gegen den Foreign Key (das ON DELETE SET NULL hier nutzt das, dazu gleich).

Da in der anderen Tabelle ein Wert auch mal gelöscht werden kann, gibt es 2 Anweisungen, wie damit umzugehen ist, wenn ein Wert, der gerade in der referenzierenden Tabelle genutzt wird, in der Tabelle, auf die verwiesen wird, gelöscht werden soll:
ON DELETE und ON UPDATE.
Da die Syntax für beide gleich ist, hier die 3 möglichen Werte:
ON DELETE RESTRICT
bedeutet: verhindere, dass ein hier genutzter Wert (bzw. die Zeile zu der er gehört) in der referenzierten Tabelle gelöscht wird.
ON DELETE CASCADE
bedeutet: wenn ein hier genutzter Wert (bzw. die Zeile zu der er gehört) in der referenzierten Tabelle gelöscht wird, lösch die entsprechende Zeile hier gleich mit.
ON DELTE SET NULL
bedeutet: wenn ein hier genutzter Wert (bzw. die Zeile zu der er gehört) in der referenzierten Tabelle gelöscht wird, setz ihn hier auf NULL

Ich habe in Erinnerung, dass das Standardverhalten ON DELETE RESTRICT ON UPDATE CASCADE sein sollte, würde dafür aber jetzt nicht meine Hand ins Feuer legen.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "REFERENCES"

Beitrag von AUGE_OHR »

bgl hat geschrieben:... welche sagt "DORT MUSS EIN KORRESPONDIERENDER EINTRAG VORHANDEN SEIN!"
ok, ich verstehe.

es wird aber damit in der "angesprochenen" Table eine "Bewegung" ähnlich einem SET RELATION ausgelöst, oder ?

Frage : gibt es dann ein Result was man überprüfen könnte ... oder ist das -> NULL ?
bgl hat geschrieben:Folgendes ist dabei zu beachten:
aha ... das sind die "Aktionen" bei den was "passieren" soll.
das muss ich mir in Ruhe mal ansehen ...

der oben von Hector erhaltene Code scheint also in dem Beispiel recht gut zu "passen" ... wenn die Table "gefüllt" ist.
gruss by OHR
Jimmy
bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: PostgreSQL "REFERENCES"

Beitrag von bgl »

AUGE_OHR hat geschrieben:
bgl hat geschrieben:... welche sagt "DORT MUSS EIN KORRESPONDIERENDER EINTRAG VORHANDEN SEIN!"
ok, ich verstehe.

es wird aber damit in der "angesprochenen" Table eine "Bewegung" ähnlich einem SET RELATION ausgelöst, oder ?

Frage : gibt es dann ein Result was man überprüfen könnte ... oder ist das -> NULL ?
Zunächst mal muss ich zu meiner Schande gestehen, dass ich mir gerade nicht mehr 100% im Klaren bin, was SET RELATION wirklich tut, fürchte aber, dass das Verhalten nur so und so weit übereinstimmt.

Ein FOREIGN KEY bewirkt zunächst einmal in der referenzierten Tabelle gar nichts - er legt lediglich eine Bedingung fest, die das Einfügen und Ändern von Werten in der referenzierenden Tabellenspalte betrifft - nämlich "hier nur Werte, die es dort schon gibt einfügen!".
Auswirkungen auf die referenzierte Tabelle haben wir erst, wenn wir ON DELETE/ON UPDATE betrachten, da die Variante 'RESTRICT' ein ganz klares Verbot des Löschens oder Änderns referenzierter Werte bewirkt, d.h. man muss erst den referenzierenden Wert löschen (ein Beispiel wo das sinnvoll wäre: wir haben eine Tabelle mit Ordnern und eine Tabelle mit Ordnerinhalten und wollen, dass nur leere Ordner gelöscht werden können - dann könnte die Tabelle mit den Ordnerinhalten ein Feld haben, was auf den Primärschlüssel der Ordnerliste verweist und ON DELETE RESTRICT hat).



Nachtrag: davon ausgehend, dass das hier: http://www.dbase.com/help/Xbase/IDH_XBA ... LATION.htm noch aktuell ist, würde ich sagen, dass SET RELATION eher einem SELECT aus mehreren Tabellen entspricht. Ich vermute mal, dass es Dinge mit FOREIGN KEYs anstellt, um zum Zeitpunkt des SET RELATION zu überprüfen, ob die Tabellen so zueinander passen, aber das ist ein Problem, das in SQL aufgrund der Sprachstruktur nicht auftreten sollte - geprüft wird beim Schreiben in die referenzierende Tabelle und beim Löschen aus der referenzierten Tabelle, jederzeit.
Was du mit der "Bewegung" meinst habe ich fürchte ich ansonsten noch immer nicht so ganz kapiert.
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL "REFERENCES"

Beitrag von georg »

Hallo, Jimmy -


es gibt keine "Bewegung". SQL operiert mit Result Sets, es gibt keine SET RELATION. Wenn Du nach der Änderung ein neues Result Set anforderst, spiegelt dies die Änderung wieder.

Du bist hier unter SQL, nicht unter Xbase++.

Ob Alaska in der dbPGE hingegangen ist und die SET RELATION durch einen jeweils erneuten SELECT aktualisiert, kann ich Dir nicht sagen, aber das ist die einzige Möglichkeit, das Verhalten von DBFNTX/FOXCDX unter SQL abzubilden.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: PostgreSQL "REFERENCES"

Beitrag von bgl »

georg hat geschrieben:Hallo, Jimmy -


es gibt keine "Bewegung". SQL operiert mit Result Sets, es gibt keine SET RELATION. Wenn Du nach der Änderung ein neues Result Set anforderst, spiegelt dies die Änderung wieder.

Du bist hier unter SQL, nicht unter Xbase++.

Ob Alaska in der dbPGE hingegangen ist und die SET RELATION durch einen jeweils erneuten SELECT aktualisiert, kann ich Dir nicht sagen, aber das ist die einzige Möglichkeit, das Verhalten von DBFNTX/FOXCDX unter SQL abzubilden.


Gruss,

Georg
CREATE TEMPORARY VIEW ...

Das ganze CURSOR-Experiment könnte aber auch etwas analoges liefern.
Antworten