Probleme bei der Erzeugung einer Tabelle

[DennisXX]

Hi Folks !

Ich bekomme immer eine Fehlermeldung, wenn ich in meinem DBMS eine Tabelle mittels CREATE Statement erstellen möchte. Ich setze hier einfach ein paar Felder, setze einen primär- und einen Fremdschlüssel mithilfe eines Constraints.

Ich bekomme explizit bei der Erstellung des Fremdschlüssels in der tabellen eine fehlermeldung. Erst wenn ich die Tabelle erstellt habe und dann mithilfe einer ALTER Anweisung den Fremdschlüsselconstraint setze, bekomme ich keine Fehlermeldung und das Statement wird vom DBMS durchgewunken.

Warum ist das eigentlich so?

Greetz
Dennis

 

[Evil-Devil]

Kannst du das Create Statement posten? Dann könnte man direkt sagen ob und was falsch ist.

 

[turtle]

Und sag uns auch welche DB?

 

[DennisXX]

Hier ist der Code:

CREATE TABLE person
(person_id SMALLINT UNSIGNED,
 vorname VARCHAR(20),
 nachname VARCHAR(20),
 city VARCHAR(20)
 CONSTRAINT pk_person PRIMARY KEY (person_id),
 CONSTRAINT fk_person FOREIGN KEY (person_id)
    REFERENCES person (person_id)
);

Greetz
Dennis

 

[Evil-Devil]

Wenn ich das richtig sehe fehlt da nach deinem letzten Feld city und vor dem references ein Komma.
AFAIK wird jede Definitionszeile beim Create Table mit einem Komma getrennt. Das sollte sogar unabhängig vom DBMS sein und direkt im SQL Standard stehen.

Richtig sollte also sein:
[sql]
CREATE TABLE person
(person_id SMALLINT(5) UNSIGNED default 0,
vorname VARCHAR(20),
nachname VARCHAR(20),
city VARCHAR(20),
CONSTRAINT pk_person PRIMARY KEY (person_id),
CONSTRAINT fk_person FOREIGN KEY (person_id),
REFERENCES person (person_id)
);[/sql]

//edit: ich hab mal noch die Größe vom Smallint angefasst und ein default gesetzt. Sonst steht da nachher noch null drin...

Ist das eigentlich richtig, dass deine ID nicht auto inkrementiert werden soll?

 

[turtle]

vor dem references ein Komma

NEIN.

jede Definitionszeile in beim Create Table mit einem Komma getrennt.

Ja, eben.

Die Definitionszeile lautet wohl:
CONSTRAINT fk_person FOREIGN KEY (person_id) REFERENCES person (person_id)

 

[Evil-Devil]

Die Definitionszeile lautet wohl:
CONSTRAINT fk_person FOREIGN KEY (person_id) REFERENCES person (person_id)

Danke, hab noch nie Constraints gesetzt, sondern immer selbst dafür Sorge getragen das die Referenzen valide sind.

 

[turtle]

Danke, hab noch nie Constraints gesetzt, sondern immer selbst dafür Sorge getragen das die Referenzen valide sind.

Echt? Da rate ich von ab, dann manchmal greift man auch "nur" via SQL auf die DB zu

 

[Evil-Devil]

Wie sollte man denn außer per SQL auf die DB zugreifen?

 

[DennisXX]

Hi Folks !

Danke für die bisherigen Beiträge. Ich möchte euch nochmal etwas fragen:

Können solche Fremschlüsseldefinitionen evtl. auch deshalb einen Fehler erzeugen, wenn die Tabelle, auf die dieser Fremschlüsselconstraint zeigt bzw. zeigen soll und codetechnisch im CREATE Statement umgesetzt wird, zu diesem Zeitpunkt noch gar nicht erzeugt wurde?

Greetz
Dennis

 

[AFlieger]

Ja

 

[turtle]

Danke, hab noch nie Constraints gesetzt, sondern immer selbst dafür Sorge getragen das die Referenzen valide sind.

Daraus habe ich verstanden, dass Dein Applikationscode sich um die Integrität kümmert.

 

[DennisXX]

Hi Folks again !

Also ist mein zuerst geschriebenes CREATE TABLE Statement in dieser Form schon richtig, aber wenn eben die Tabelle, auf die mittels eines Fremdschlüsselconstraints verwiesen werden soll, noch nicht erzeugt wurde, erhalte ich eine Fehlermeldung bei der Durchführung des CREATE TABLE Statements. Ist das so jetzt halbwegs korrekt?

Greetz
Dennis

 

[Evil-Devil]

Daraus habe ich verstanden, dass Dein Applikationscode sich um die Integrität kümmert.

Tut er in gewisser Weise. Aber die Intigrität beginnt bereits beim DRM Design. Da die Inserts ohnehin sequentiell abgearbeitet werden, müssen das die Deletes auch sofern es notwendig ist.

Das letzte Mal das ich Referentielle Intigrität genutzt habe war bei Access...zum verhindern von versehentlichen löschen durchaus praktisch. Nur was tut man, wenn man den einen oder anderen Eintrag trotz des RI Schutzes löschen will?

Dennis, wir haben dein Create Statement doch schon korrigiert. Dir fehlte lediglich ein Komma. Wenn du das Statement ausführst sollte SQL eine Syntax Fehlermeldung erzeugen.

 

[DennisXX]

Danke schön für die Beteiligungen !

Greetz
Dennis

 

[bERt0r]

Also ich weis ja nicht:

CREATE TABLE person
(person_id SMALLINT UNSIGNED,
 CONSTRAINT pk_person PRIMARY KEY (person_id),
 CONSTRAINT fk_person FOREIGN KEY (person_id)
    REFERENCES person (person_id)
);

Warum ist person_id gleichzeitig der Primary Key und Referenziert auch noch ein weiteres person_id in der gleichen Tabelle (das kann ja nur eine rekursive Beziehung sein). Abgesehen davon, dass so ein Konstrukt unsinnig ist, weis ich auch nicht ob die DB das zulässt, und wenn wirst du wohl deine Probleme mit Inserts auf diese Tabelle haben.