✔ SQL - constraint reference on update cascade

[flashray]

Hallo,

Die folgenden Anweisungen sind aus dem Aufgabentext eines DBMS Übungsblattes. Bin mir aber im unklaren ob diese so korrekt sind.

Hätte zwei Fragen dazu:
1. Macht die Bedingung "constraint vname..." im table Tickets Sinn? Oder müsste dort foreign key(Veranstaltung) stehen?
2. Welchen Nutzen hat dieses "on update cascade" bei dem constraint vname? Es wäre doch "on delete cascade" sinvoller! Denn, wenn eine Veranstaltung entfällt, so sollten dann auch die zugehörigen Tickets erloschen.

create table Veranstaltung (
Veranstaltung	varchar(100) not null primary key,
Datum		date,
Ort		varchar(100));

create table Tickets (
TicketNr		integer not null primary key,
Preis			decimal(10,2),
Veranstaltungsname	varchar(100),
constraint vname
	foreign key(Veranstaltungsname)
	references Veranstaltung
	on update cascade);

create table Verkauft (
TicketNr	integer not null primary key,
KundenNr	integer,
constraint ticket
	foreign key(TicketNr)
	references Tickets,
	constraint kunde
	foreign key(KundenNr)
	references Kunde
	on delete cascade);

create table Kunde (
KundenNr	integer not null primary key,
Name		varchar(100),
Wohnort	varchar(100));

Vg Erdal

 

[Nico Graichen]

Hi,

Also eigentlich müsste das so sein:

ALTER TABLE table 
    ADD CONSTRAINT constraint_name 
    FOREIGN KEY (column) 
    REFERENCES ref_table (ref_column) 
    ON UPDATE CASCADE

 

[flashray]

Hallo Niggo,

ALTER TABLE table 
    ADD CONSTRAINT constraint_name 
    FOREIGN KEY (column) 
    REFERENCES ref_table (ref_column) 
    ON UPDATE CASCADE

Ok. Nach diesem Schema fehlt für vname die Angabe ref_column.

Was passiert wenn ref_column nicht angegeben ist.
1. Anweisung fehlerhaft?
2. ref_column entspricht der Spalte von ref_table mit dem gleichen Namen wie column?
3. ref_column ist implizit die Spalte mit dem Primärschlüssel von ref_table?


Vg Erdal

 

[THMD]

N'Abend

Also eigentlich müsste das so sein:

ALTER TABLE table 
    ADD CONSTRAINT constraint_name 
    FOREIGN KEY (column) 
    REFERENCES ref_table (ref_column) 
    ON UPDATE CASCADE

Nein muß es nicht! Wenn keine Spalte angegeben wird, nimmt er automatisch den Primary Key der Tabelle. Oracle macht das z.B. so und imho ist das auch in SQL standardisiert.

1. Macht die Bedingung "constraint vname..." im table Tickets Sinn? Oder müsste dort foreign key(Veranstaltung) stehen?

Ja sie macht Sinn. Veranstaltungsname ist ein Fremdschlüssel von Ticket auf den Primärschlüssel der Tabelle Veranstaltung. Sprich du kannst bei den Tickets nur Veranstaltungsnamen erzeugen, die es auch als Veranstaltung gibt.

Welchen Nutzen hat dieses "on update cascade" bei dem constraint vname? ...

Naja, wenn du den Namen einer Veranstaltung in der Tabelle Veranstaltung änderst, wird damit auch der Veranstaltungsnahme des Tickets geändert - macht schon Sinn, wenn du z.B. Tickets ausdrucken möchtest, dann sollten die auch den aktuellen Namen der Veranstaltung haben.

gruß
THMD

 

[flashray]

Vielen Vielen Dank THMD,

hast alle meine offenen Fragen geklärt. Jetzt kann ich endlich das Übungsblatt bearbeiten.


Auch nochmals herzlichen Dank dir, Niggo!


Vg Erdal

 

[ishino]

Nebenbei sei bemerkt, das ON UPDATE CASCADE nicht in allen DBS verfuegbar ist - und das aus gutem Grund - Oracle ist zum Beispiel eines davon.

 

[flashray]

Hallo Ishino,

Nebenbei sei bemerkt, das ON UPDATE CASCADE nicht in allen DBS verfuegbar ist - und das aus gutem Grund - Oracle ist zum Beispiel eines davon.

wenn wir schon beim Thema sind was ist dieser gute Grund?


Vg Erdal

 

[ishino]

CASCADE Constraints beziehen sich auf Primärschlüssel und die sollten als solche unveränderlich sein, ansonsten sind es keine (bzw. nur Schlüsselkandidaten, dann muß halt ein künstlicher Schlüssel her, wenn es nicht anders geht). Ein UPDATE auf einem Primärschlüssel ist demzufolge bei einem vernünftigen Design nicht notwendig und deshalb braucht es auch kein ON UPDATE CASCADE.

 

[flashray]

D a n k e.