[code]-- create table testone
CREATE TABLE dbname.testone( id INT(5) NOT NULL AUTO_INCREMENT, parent VARCHAR(10) NOT NULL COMMENT ‘the big boss’,
PRIMARY KEY(id, parent)
) ENGINE=MYISAM DEFAULT CHARSET=latin1 COLLATE latin1_german1_ci AUTO_INCREMENT=1;
– create table testtwo
CREATE TABLE dbname.testtwo( id VARCHAR(10) NOT NULL REFERENCES testone(parent) ON UPDATE CASCADE ON DELETE RESTRICT PRIMARY KEY, something VARCHAR(10) NULL DEFAULT NULL’
) ENGINE=MYISAM DEFAULT CHARSET=latin1 COLLATE latin1_german1_ci;[/code]
Jetzt füge ich in die erste einfach zum Test die beiden werte ‘1’ und ‘test’ und in die zweite ‘test’ und NULL ein. Jetzt ändere ich in der ersten ‘test’ auf ‘teststring’ ab, aber in der zweiten bleibt aber ‘test’ bestehen. Müsste da jetzt nicht auch ‘teststring’ drinstehen???
Also habe ich diese beiden Tabellen als InnoDB erstellt, aber trotzdem kann in der parent-Spalte ich ändern wie ich lustig bin; dem Kind interessiert das nicht die Bohne.
auch, wenn ich describe testtwo ausführe, finde ich keinen Anhaltspunkt, dass ein foreign key existieren würde
[quote=“do-it-yourself”]Re: Für was brauche ich MySQL wenn ich immer noch keine Integrität habe???
Also habe ich diese beiden Tabellen als InnoDB erstellt, aber trotzdem kann in der parent-Spalte ich ändern wie ich lustig bin; dem Kind interessiert das nicht die Bohne.[/quote]
Kann es sein, dass du eine vollkommen falsche Vorstellung von dem Begriff Integrität hast …?
Warum sollte es?
Es ist nicht Sinn und Zweck solcher Datenbanken, die Daten redundant vorzuhalten.
Wenn das wirklich zwei verschiedene Datenstrukturen sind, und die Änderung von “test” auf “teststring” sich in beiden auswirken soll - dann wäre Normalisierung angesagt, Auslagern des Wertes.
Vielleicht suchst du aber auch schlicht und einfach Views?
Schwer zu sagen, weil du ja nicht wirklich beschreibst, was genau du eigentlich erreichen willst.
Ein foreign-Key-Constraint sollte dafür zuständig sein, dass ein Eintrag in einer Spalte einer Tabelle immer auf einen validen Eintrag in einer Spalte einer anderen Tabelle (oder der selben) zeigt.
Dass InnoDB diese Constraints einhalten kann, ist sicher. Allerdings macht das Ändern eines solchen Eintrages normalerweise nur bedingt Sinn und normalerweise verwendet man das für Integer-Datentypen.
das war nur ein Test mit strings. Aber egal, ich lass die dinge sowieso mit php überprüfen. Ich hatte in der Uni eine einzige Doppelstunde Vorlesung über SQL und da wurde nur kurz drübergewischt. Hauptsächlich ging es um das ER-Modell. Hätte mich nur mal interessiert.
hat sich erledigt 
