SQL Frage

[Gast]

Was ist der unterschied ob ich mache:

create table studenten(
name char(10),
matnr int primary key,
studiengang char(3) references studiengänge(bezeichnung);

oder:

create table studenten(
name char(10),
matnr int primary key,
studiengang char(3) CONSTRAINT fk_stug_stg REFERENCES studiengänge(bezeichnung);


beides mal soll die spalte studiengang der tabelle studenten ein Fremdschlüssel zu der tabelle studiengänge sein.

Fügt das Contraint nur einen alias hinzu?

was ist der unterschied zu:


create table studenten(
name char(10),
matnr int primary key);

ALter table studenten add Constraint fk_xy FOREIGN Key (studiengang) References studiengänge(bezeichnung);

[samm]

Beim zweiten Beispiel ist der Foreign Key explizit über den Namen ansperchbar, sobald man noch eine Klammer mehr zumacht, sonst: syntax error ;) Das letzte wird ohnehin nicht funktionieren, da es studiengang gar nicht gibt in der Tabelle studenten.
Und allgemein find ich jetzt char(3) für einen key nicht so toll. Ich ziehe da numerische Werte vor, aber vielleicht bin ich nur altmodisch.

[The_Invisible]

ich kenne ne anwendung mit textfeldern als key, wird schon seine gründe haben (oder auhc nicht) :D

mfg

[daflow]

Beim zweiten Beispiel ist der Foreign Key explizit über den Namen ansperchbar, sobald man noch eine Klammer mehr zumacht, sonst: syntax error ;) Das letzte wird ohnehin nicht funktionieren, da es studiengang gar nicht gibt in der Tabelle studenten.
Und allgemein find ich jetzt char(3) für einen key nicht so toll. Ich ziehe da numerische Werte vor, aber vielleicht bin ich nur altmodisch.

Und 2.eres kenn ich so auch nicht, in welchem DBMS soll das funktionieren oder was für ein constraint machen? (Check constraint, foreign key...? ... müsste normalerweise dabei stehen).


Ob du den foreign key gleich beim create table erstellst oder danach ein "alter table add constraint foreign key blafasel ..." machst ist egal. Ein Foreign Key ist immer ein Constraint aber nicht jedes Constraint ein foreign key ;)
Weiterhin, wie shcon erwöhnt: Wenn du einem Constraint keinen Namen gibst, dann vergibt das DBMS einen ... und das ist meisst nicht gerade ein sprechender Name... wenn du also später mal wieder was mit dem Constraint machen willst, dann darfste erstmal suchen

[samm]

Und 2.eres kenn ich so auch nicht, in welchem DBMS soll das funktionieren oder was für ein constraint machen?Ich habe hier zu Hause nur das MySQL und Postgres-Manual verlinkt, da findest du die entsprechenden Einträge hier: http://dev.mysql.com/doc/refman/5.1/de/create-table.html und hier: http://www.postgresql.org/docs/8.3/interactive/ddl-constraints.html

[daflow]

Ich habe hier zu Hause nur das MySQL und Postgres-Manual verlinkt, da findest du die entsprechenden Einträge hier: http://dev.mysql.com/doc/refman/5.1/de/create-table.html und hier: http://www.postgresql.org/docs/8.3/interactive/ddl-constraints.html


Ich find da nix auf den Seiten, immer wenn da "CONSTRAINT" steht kommt auch danach die Formulierung was für eins (Unique, Check, FK, PK...).
"Constraint" ohne Angabe um für eins es sich handelt seh ich da nich?
OK in Postgres scheints laut create Syntax zu funktionieren: http://www.postgresql.org/docs/8.3/interactive/sql-createtable.html

[samm]

Du hast beim ersten Mal recht gehabt. Hab das wohl beim Lesen automatisch auf "Foreign Key" korrigiert :/ Auch bei Postgres geht es nicht, in der von dir verlinkten Stelle ist zwar CONSTRAINT optional, nicht aber FOREIGN KEY, ausser ich überseh was.

[Gast]

in oracle geht das angegebene kommando

[Gast]

1.) Bitte tut euch den Gefallen und setzt bei jeder Tabelle einen Integer als Primary Key und verlinkt über den. Wenn man anfängt über chars herum zu murksen, dann kommt meistens nicht viel dabei raus. Was glaubst du passiert, wenn ein Studiengang umbenannt wird (ist bei mir sogar 2 mal passiert) oder man einmal eine Erweiterung macht und auch Studiengänge von anderen Unis dabei hat. Das ist wahrscheinlich nur eine Hausaufgabe, aber in der Realität wäre das fatal, weil Datenbanken oft 20 Jahre und mehr leben und man nicht einfach mit drop database von neu beginnen kann. Ich nehme hier immer einen Auto Wert. Das ist bis auf die Tatsache, dass man ihn schwer manuell reproduzieren kann die sicherste Variante. Abgesehen davon kommt man vor allem als Anfänger nicht in die Gefahr, dass man falsche Annahmen über die Eindeutigkeit von Werten trifft z.B. würden viele Leute eine Sozialversicherungsnummer als eindeutig hernehmen und bedenken nicht, dass man vielleicht Leute hat, bei denen diese entweder nicht bekannt ist oder die im Ausland versichert sind. Oft wird eine Person gelöscht und neu angelegt. Sobald es Verknüpfungen gibt (z.B. Bestellungen eines Kunden) kann man den Datensatz nur mehr inaktiv setzen und dann hat man den Salat.
Kommt man bei einem normalen Feld später drauf, kann man einfach den Unique Index entfernen, bei einem Primary Key geht das nicht so leicht.

2.) Ich empfehle generell zuerst alle Tabellen zu erstellen, dann alle Primärschlüssel und dann alle Fremdschlüssel. Danach kommen alle Indizes. Das hat mehrere Vorteile:
a) Es spielt keine Rolle, in welcher Reihenfolge man die Tabellen anlegt. Es gibt auch Datenbanken, wo es dann keine Kombination mehr gibt (z.B. bei Tabellen, die auf sich gegenseitig verweisen in unterschiedlichen Funktionen oder auf sich selbst)
b) Man hat fülle alle Schlüssel und Indizes einen schönen, sprechenden Namen und nicht irgendwelche Nummern, aus denen keiner schlau wird. Das ist besonders lustig, wenn die Datenbank und Tabellen etwas größer werden
c) Wenn man bestehende Daten importiert, so kann man diese einfügen, bevor man die Schlüssel hinzufügt, vorausgesetzt man prüft im vorhinein, ob die Daten auch konsistent sind, sonst schlägt das Erstellen der Indizes fehl. Ein Einfügen ohne Indizes ist um Welten schneller.