Seite 1 von 1
PostgreSQL "REFERENCES"
Verfasst: Sa, 28. Jul 2012 23:50
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 (62.98 KiB) 8058 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.
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 ?
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"
Re: PostgreSQL "REFERENCES"
Verfasst: Mo, 30. Jul 2012 5:04
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.
Re: PostgreSQL "REFERENCES"
Verfasst: Do, 02. Aug 2012 0:33
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.
Re: PostgreSQL "REFERENCES"
Verfasst: Do, 02. Aug 2012 0:47
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.
Re: PostgreSQL "REFERENCES"
Verfasst: Do, 02. Aug 2012 0:57
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.
Re: PostgreSQL "REFERENCES"
Verfasst: Do, 02. Aug 2012 6:51
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
Re: PostgreSQL "REFERENCES"
Verfasst: Do, 02. Aug 2012 9:28
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.