InnoDB foreignkey Beziehungen

[Forumsgast]

Hi,
wollte mal so ne allgemeine Diskussion zu den foreignkey Beziehungen von MySQL anwerfen.

Bis jetzt habe ich diese Beziehungen noch nie genutzt, also genauer genommen die ON DELETE bzw. ON UPDATE Funktionalität.

Nutzt ihr das? Ist bestimmt praktisch um eine bestimmte Datenintegrität zu halten, allerdings ist es auch relativ gefährlich wenn man nicht aufpasst.

Also wieso nutzt ihr sie bzw. wieso lasst ihr lieber die Finger davon??

Gruß Flo

[Forumsgast]

Also ich nutze es nicht. Ich bin der Meinung die Integrität lässt sich über eine ordentliche Programmierung recht gut gewährleisten. Wenn man dazu dann noch Transaktionen unter MySQL nutzt, dann kann mit sauberem Code doch überhaupt nichts mehr passieren oder?

[Forumsgast]

Nein dass nicht. Aber bei einem sauberen Datenbankdesign spart man sich so auch wiederum viel Arbeit. Bis jetzt habe ich es auch so gehandhabt immer per PHP die Daten dann noch zu löschen die an nem Datensatz dran hängen.

Aber irgendwie ist es doch bestimmt recht praktisch dass direkt von der Datenbank tuen zu lassen. Wobei teilweise ja noch andere Aufräumarbeiten erledigt werden müssen wenn ein Datensatz gelöscht wird und diese dann trotzdem wieder per PHP gemacht werden müssten ...

[Forumsgast]

Ich nutze constraints ausgiebig (wenn auch nicht in MySQL).
Also zum Beispiel

order_id integer REFERENCES orders ON DELETE CASCADE,

Mit sonstigen Triggern oder stored procedures bin ich vorsichtig/sparsam, aber die Integritätsprüfung packe ich nach Möglichkeit in die Datenbank.

[Forumsgast]

Nein dass nicht. Aber bei einem sauberen Datenbankdesign spart man sich so auch wiederum viel Arbeit. Bis jetzt habe ich es auch so gehandhabt immer per PHP die Daten dann noch zu löschen die an nem Datensatz dran hängen.

Aber irgendwie ist es doch bestimmt recht praktisch dass direkt von der Datenbank tuen zu lassen. Wobei teilweise ja noch andere Aufräumarbeiten erledigt werden müssen wenn ein Datensatz gelöscht wird und diese dann trotzdem wieder per PHP gemacht werden müssten ...

mit begründungen wie "es ist auch ganz praktisch" lass ich mich nicht überzeuegen. es ist schließlich auch ganz praktisch, das man in php keine variablen initalisieren muss....
beides richtig zu machen ist einfach sauberer. da siehst du dann im quellcode -> ok hier wird aufgeräumt, da was upgedatet. aber warum man das in Structuered Query Language machen muss, ist mir schleierhaft. (und wenn du dann in oracel per sql exceptions abfängst, denk an mich ).

Also ich nutze es nicht. Ich bin der Meinung die Integrität lässt sich über eine ordentliche Programmierung recht gut gewährleisten. Wenn man dazu dann noch Transaktionen unter MySQL nutzt, dann kann mit sauberem Code doch überhaupt nichts mehr passieren oder?

das finde ich eigentlich auch. wobei man das auch auf joins anwenden kann...

[Forumsgast]

Hmm, ich nutze es auch nicht. Aber an sich finde ich den Ansatz gut, die Belange der Datenschicht auch dort abzuhandeln. Noch ein paar Views auf typische Joins und einige Stored procedures und PHP muß sich nicht mehr groß um SQL Belange kümmern. Eigentlich doch ne gute Idee.

[Forumsgast]

Warum muss man etwas mit PHP machen wenn SQL das bei richtiger Konfiguration von sich aus selbst kann ?

Nutzt ihr das? Ist bestimmt praktisch um eine bestimmte Datenintegrität zu halten, allerdings ist es auch relativ gefährlich wenn man nicht aufpasst.

Wenn man die Beziehungen falsch in seinem Design anlegt ... klar, dann ist es gefährlich, aber für sowas testet man seinen Code ja und wenn man es benutzt sollte man auch wissen was man tut. Include in PHP kann bei falscher Handhabung auch SEHR gefährlich sein:

<?php include($_GET['action']);

[Forumsgast]

mit begründungen wie "es ist auch ganz praktisch" lass ich mich nicht überzeuegen. es ist schließlich auch ganz praktisch, das man in php keine variablen initalisieren muss....
beides richtig zu machen ist einfach sauberer. da siehst du dann im quellcode -> ok hier wird aufgeräumt, da was upgedatet. aber warum man das in Structuered Query Language machen muss, ist mir schleierhaft. (und wenn du dann in oracel per sql exceptions abfängst, denk an mich ).



das finde ich eigentlich auch. wobei man das auch auf joins anwenden kann...

ups das war ich. hab hier wohl noch nen 2. account

Warum muss man etwas mit PHP machen wenn SQL das bei richtiger Konfiguration von sich aus selbst kann ?

gegenfrage: warum muss sql etwas können, das eine "richtige" sprache besser und variabler kann?

[Forumsgast]

Ich weiss nicht, richtig praktisch fände ich es erst wenn MySQL mir das Joinen damit vereinfachen würde. Ich meine was nützt es mir wenn ich die Beziehungen festlege und dann trotzdem bei jedem Join ihm nochmal sagen muss wie die Beziehung aussieht? Dann doch lieber ein solides Framework was die Tabellen und deren Beziehungen kennt. Der macht dann sowohl die Update-/Löschweitergabe als auch das eigenständige joinen. Klar sinnvoll wäre wenn man so viel wie möglich der Datenbank überlassen würde und nur das eigenständige joinen dem Framework überlässt, aber wer steigt dann noch durch was wo geregelt ist?

[Forumsgast]

Naja, mysql kann es Warum sollte man es dann nicht auch nutzen ?

Ich muss dir schon zustimmen, variable ist das was mysql da kann nicht, aber wenn man keine Variabilität braucht und einfache Verknüpfungen hat dann reicht es und spart einem auch den Mehraufwand das ganze in php zu implementieren.

[Forumsgast]

gegenfrage: warum muss sql etwas können, das eine "richtige" sprache besser und variabler kann?

Was bedeutet denn "besser"? Ich denke mit wenn das die Datenbank direkt macht dann ist das "besser". Eigentlich finde ich den Gedanken dass die komplette Datenintegrität und Bereitstellung von der Datenbank übernommen wird und PHP wirklich nur noch dafür zuständig ist die Daten zu lesen bzw. hinzuzufügen/löschen. Aber dass die Daten intern in der Datenbank konsistent gehalten werden sollte eher in der Abstraktionsebene der Datenbank bleiben.

[Forumsgast]

Ich weiss nicht, richtig praktisch fände ich es erst wenn MySQL mir das Joinen damit vereinfachen würde. Ich meine was nützt es mir wenn ich die Beziehungen festlege und dann trotzdem bei jedem Join ihm nochmal sagen muss wie die Beziehung aussieht? Dann doch lieber ein solides Framework was die Tabellen und deren Beziehungen kennt. Der macht dann sowohl die Update-/Löschweitergabe als auch das eigenständige joinen. Klar sinnvoll wäre wenn man so viel wie möglich der Datenbank überlassen würde und nur das eigenständige joinen dem Framework überlässt, aber wer steigt dann noch durch was wo geregelt ist?

Naja genau das machen ja z.b. ORM-Systeme wie Propel und Doctrine. Die erzeugen ihre Models und daraus die Tabellen abhängig davon was für eine Datenbank und was für eine Engine zum Einsatz kommen. Beim erstellen der Tabellen aus den Konfigurations-Dateien bzw Models werden die Passenden Klassen und Tabellen erzeugt die dann beim löschen/updaten von Einträgen das ganze automatisch regeln, also entweder nur den Eintrag löschen und damit die Kette anstoßen oder mit zusätzlichen Querys die Bedingungen erfüllen.

[Forumsgast]

Ja natürlich, aber wie gesagt, wer steigt dann da noch durch? Ich meine du verteilst die Relationen somit auf 2 Ebenen. Den einen Teil übernimmt die Datenbank, den anderen übernimmt das Framework und die Beziehungen sind gleich 2 mal abgebildet. Ich meine das kann jeder sehen wie er will, aber ich habe lieber alles zusammen und einheitlich geregelt. Wenn MySQL den kompletten Part übernehmen könnte, dann wäre ich auch absolut dafür das ganze der Datenbank zu überlassen. Die Update-/Löschweitergabe ist schon ein schöner Schritt in die richtige Richtung und ich hoffe da kommt noch mehr

[Forumsgast]

Ja natürlich, aber wie gesagt, wer steigt dann da noch durch? Ich meine du verteilst die Relationen somit auf 2 Ebenen. Den einen Teil übernimmt die Datenbank, den anderen übernimmt das Framework und die Beziehungen sind gleich 2 mal abgebildet. Ich meine das kann jeder sehen wie er will, aber ich habe lieber alles zusammen und einheitlich geregelt. Wenn MySQL den kompletten Part übernehmen könnte, dann wäre ich auch absolut dafür das ganze der Datenbank zu überlassen. Die Update-/Löschweitergabe ist schon ein schöner Schritt in die richtige Richtung und ich hoffe da kommt noch mehr

Das Problem ist ja dass man nicht immer weis ob mysql es kann!
Nur wenn InnoDB als Storage-Engine aktiviert ist, die Tabellen dementsprechend angelegt sind, kann mysql sowas. Wenn man also ein System bastelt das vielleicht auf verschiedenen Hosts laufen soll, nimmt einem der ORM-Mapper hier die Arbeit ab und schaut ob der Arbeit auf mysql abladen kann, ansonsten machen die Models es selbst.

Als Benutzer passiert das ganze ja quasi transparent im Hintergrund, man muss sich dadurch eben keine Sorgen mehr darum machen

[Forumsgast]

Ich meine was nützt es mir wenn ich die Beziehungen festlege und dann trotzdem bei jedem Join ihm nochmal sagen muss wie die Beziehung aussieht?

Die Antwort kannst Du Dir aber selbst geben. Weil nicht immer JOIN notwendig ist. Wenn ich eine Userdetailtabelle mit einer Account-Tabelle verknüpfe, dann brauch ich nicht in jeder Profilabfrage automatisch Accountdaten auszulesen.