[MYSQL] InnoDB Beziehung 1:n ... n = 0 ?

[Aiun]

hi,

folgender fall

habe Tabellen A und B

A hat eine 1:n Beziehung zu B

ergo, in phpmyadmin - beziehungsübersicht ist für B der Primärschlüssel A_ID der tabelle A angegeben. onupdate und ondelete "NO ACTION"

leider kann ich jetzt nicht sagen, A_ID von B = 0. Also, dieser Datensatz von B hat eben "keinen" A-Datensatz übergeordnet.

da bekomme ich dann den fehler "Cannot add or update a child row: a foreign key constraint fails"

bisher war der Fremdschlüssel auf einem Wert. Aber jetzt muss ich eben die Verbindung lösen.

kann mir jemand sagen was ich einstellen muss damit er auch "0" als Fremdschlüssel-Wert akzeptiert ?

danke

[Jaraz]

Hi,

0 ist ein Wert

kein Wert ist bei sql NULL

Ob NULL akzeptiert wird, hängt auch von der Konfiguration der Tabellenspalte für den Fremdschlüssel ab.

Gruß Jaraz

[baba007]

das ganze nennt sich meines Wissens referentielle Integrität und ist auch so beabsichtigt. DU musst zuerst die Beziehung löschen und erst dann den Datensatz.

Das heisst der Datensatz aus B muss gelöscht werden, dann der aus A. Du kannst aber nicht das Feld, selbstständig löschen oder manuell ändern wo kein DS in A entsprechend vorliegt.

[Aiun]

ja, das ist referenzielle Integrität, scheint nur in InnoDB besch**** umgesetzt zu sein.

Selbst wenn die beziehung richtig eingestellt ist (wenn A gelöscht wird, lösche alle von B die damit verbunden sind) gibts nur fehlermeldung. *ARGH* da handle ich die Integrität lieber durch die Datenabstraktionsschicht der Anwendung.

[Jaraz]

Klar, eine Engine die Millionenfach eingesetzt wird, arbeitet fehlerhaft und nur du merkst es.

Wenn z.B. auf die zu löschenden Datensätze weitere Referenzen liegen, könnten die natürlich nicht gelöscht werden.

Gruß Jaraz

[perdian]

ja, das ist referenzielle Integrität, scheint nur in InnoDB besch**** umgesetzt zu sein.

Wenn es tatsächlich so einfach wäre: Glaubst du nicht, dann wäre diese einfache(re) Lösung schon längst implementiert?

Oder anders ausgedrückt: Wenn es tatsächlich so schlecht umgesetzt worden ist, dann stelle einen Bug ein oder setze dich selber an eine "richtigere" Lösung. OpenSource Software lebt vom mitmachen.

[Aiun]

das war eine frustantwort ^^

Das Problem ist, das selbst wenn ich die Datenbank ändere / tabellen löschen und neu einspielen will, (phpmyadmin) ich nur Fehlermeldungen bekomme

"Cannot add or update a child row: a foreign key constraint fails"

je nachdem wo ich einen Datensatz anlege -

Beispiel: Tabelle mit 2 Fremdschlüsseln und beim Create wird nur 1 Fremdschlüssel gefüllt

gleicher Fehler.

@Jaraz, ich sage nicht das sie Fehlerhaft ist. Nur ist die Nutzbarkeit sehr eingeschränkt.

1. Muss ich bei vielen Änderungen erst die Verweise entfernen

2. bekomme ich keine eindeutige Fehlermeldung, nur "ein Verweis funzt nicht"

Mein ziel ist eigentlich nur, das wenn ein übergeordneter Datensatz gelöscht wird, der untergeordnete mit oder nicht-mit gelöscht wird. Abhängig davon ob es einen übergeordneten Datensatz gibt (FK_ID != null oder 0, mir wurscht)

^^ das seeehr viele Leute ein bestimmtes Betriebssystem benutzen, macht es auch nicht besser ^^

[Aiun]

ich schmeiße mal eine Frage hinterher

kann Mysql / InnoDB mit dem Dateisystem vom betriebssystem arbeiten ?

Der Fall ist das eines der Fehler ein Dateiname ist, die datei wird mit PHP abgespeichert und der name dann eingefügt. Ich würde nun gerne aber die Datei mit in die transaktion aufnehmen, so das sie gelöscht wird, sollte die Transaktion fehlgeschlagen.

Die Datei an sich brauche ich aber nicht in der Datenbank.

hmm, ich prüfe gerade die Tabellenstruktur. Das problem mit optionalen Relationen scheint wirklich auf fehlende "null" Einstellungen in der Struktur zu beruhen.

[perdian]

kann Mysql / InnoDB mit dem Dateisystem vom betriebssystem arbeiten ?

Das kommt darauf an, was du unter 'arbeiten' verstehst. Ich habe mich noch nicht ausführlich genug mit Triggern unter MySQL 5 beschäftigt, aber könnte mir vorstellen, dass es eine Lösung gibt, wo aus einem Trigger heraus irgendein Befehl ausgeführt werden kann, mit dem die Datei physikalisch auf dem Dateisystem gelöscht wird.

Aber selbst wenn es diese Möglichkeit tatsächlich gibt: Das schreit geradezu nach schlechtem Stil und Problemen. Das fängt an bei Sicherheitsproblemen (was machst du, wenn aus irgendwelchen Gründen /bin/bash in die Datenbank kommt um beim Löschen des Datensatzes plötzlich Teile des Betriebssystems verschwunden sind?) und geht über zu massiven Synchronisierungsprobleme zu allem möglichen sonst.

Die Datenbank hat mit dem Filesystem erstmal nichts zu tun und alles, was eine Verbindung zwischen beiden schaffen muss/sollte als Zwischenschicht implementiert werden.