Fremdschlüssel und PHPmyAdmin

[mkScheller]

sers,

nachdem ich verstanden habe, was ein Foreign Key [=Fremdschlüssel(?)] ist, stellt dich mir die Frage, ob dies in phpMyAdmin irgendwie 'symbolisiert' wird?

Ich habe 2 Tabellen: Kunde und Termin, jeder Kunde hat n Termine, also gehört in Termin der PrimaryKey von Kunde als ForeignKey, richtig?

Wie realisiert man das in phpMyAdmin?

[baba007]

foreign key [id](spalte/n) references tabelle(spalte/n)

bitte beachte, dass beide Tabellen im InnoDB format sein muessen und auch nicht temporär

[mkScheller]

also ist eigentlich nicht notwendig, da man per sql die abfrage entsprechend anpasssen kann?

SELECT k.name, t.datum FROM kunde k, termin t WHERE name="maxmustermann"

wenn man jetzt davon ausgeht, dass ich nur den name als primary key in kunde habe und ihn ebenfalls als foreign key in termin verwende?

[baba007]

beim select ist es auch ziemlich wurscht ob du ein foreignkey hast oder nicht.

beim insert, update und vor allem delete wird die Sache erst wirksam...

dann stösst die DB alles ab was keine referentielle integrität aufweist

[~Hawkeye~]

Das Select wird doch schon durch Foreign Keys beeinflusst. Ein Join ist zwar manchmal langsamer eine Wherebedingung aber auf jedenfall effektiver.

Beim Insert ist es wirklich schnuppe, da hier eh erst der Primary Key geschrieben wird und dann der Primary Key wieder ausgelesen und dann in die referenzierten Tabellen als Foreign Key geschrieben werden muss. In php zum Beispiel mit mysql_insert_id() - liefert den zuletzt eingefügten Autowert, also den Primärschlüssel, wenn es ein autoincrement Feld ist.

Ab der neuen phpmyadmin- Version ist es auch möglich die Referenzen über die Oberfläche zuerstellen. Verwirrend ist da nur, dass es auch bei den MyIsam Tabellen anscheinend funktioniert. Ich war bis jetzt auch der Meinung, dass ein cascade on delete oder update nur mit InnoDB möglich ist.

Die SQL- Synatax für einen Foreign Key ist übrigens:

ALTER TABLE tabellenname ADD FOREIGN KEY (Foreign Key in Tabelle REFERENCES tabelle a (Primary Key aus Tabelle A) ON DELETE CASCADE

Durch das ON DELETE oder ersatz bzw. ergänzungsweise ON UPDATE CASCADE wird erst das ermöglicht wieso ein Fremdschlüssel so sinnvoll sein kann. Ich lösche durch mein Programm einen Primärschlüssel aus Tabelle A und nun geht das DBMS für mich her und löscht alle Datensätze, die mit einem aus Tabelle A durch Fremdschlüssel verknüpft sind. Erst dadurch wird eine referentielle Integrität erreichbar, da ich auch die DELETES auf die Fremdschlüssel durch mein Programm erledigen könnte, nur was passiert, wenn mein Programm abschmiert? Es könnten leichen zurückbleiben, die ich nur noch schwer bzw. nur noch manuell ausfiltern könnte. Und bei mehreren Tausend Datensätzen ist das schon eine Menge Arbeit.

Die referentielle Integrität sagt einfach nur aus, dass alle Kinder (Fremdschlüssel) des Vater (Primärschlüssel) Datensatzes mit dem Vater in Beziehung stehen müssen. Sollte es Kinder ohne Vater geben, so ist die Datenbank inkonsistent.

[~Hawkeye~]

Noch als Ergänzung (doofe 15 Minuten Regelung)

Die Theorie zur refentiellen Integrität könnte man nun noch um eine nicht obligatorische (kann) Beziehung ergänzen. Oben habe ich eine obligatorische (muss) Beziehung beschrieben.

Bei der nicht obligatorischen Beziehung darf es zwar einen Vater ohne Kinder geben aber keine Kinder ohne Vater.

Das sollte aber für den Anfang aber schon fast zuviel an Theorie sein.

[mkScheller]

Danke für die Antworten, die helfen mir sehr weiter und haben mir gerade 3 jahre im Fach Datenbanken endlich verständlich gemacht; jetzt weiss ich auch, was referenzielle Integ. ist.

Thanks