# Probleme bei der Erzeugung einer Tabelle



## DennisXX (4. Aug 2011)

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 (4. Aug 2011)

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


----------



## turtle (4. Aug 2011)

Und sag uns auch welche DB?


----------



## DennisXX (4. Aug 2011)

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 (4. Aug 2011)

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 (4. Aug 2011)

> 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 (4. Aug 2011)

turtle hat gesagt.:


> 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 (4. Aug 2011)

> 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 (4. Aug 2011)

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


----------



## DennisXX (4. Aug 2011)

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 (4. Aug 2011)

Ja


----------



## turtle (4. Aug 2011)

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



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


----------



## DennisXX (4. Aug 2011)

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 (4. Aug 2011)

turtle hat gesagt.:


> Daraus habe ich verstanden, dass Dein Applikations*code *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 (4. Aug 2011)

Danke schön für die Beteiligungen !

Greetz
Dennis


----------



## bERt0r (5. Aug 2011)

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.


----------

