Laden...

Fremdschlüsselbedingung schlägt fehl

Erstellt von echdeneth vor 4 Jahren Letzter Beitrag vor 4 Jahren 6.388 Views
echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 4 Jahren
Fremdschlüsselbedingung schlägt fehl

verwendetes Datenbanksystem: <MySQL>

Hallo, ich habe 2 Tabellen die über eine 1:N beziehung verknüpft werden sollen.
In fraglicher Spalte die den Fremdschlüssel (N) enthalten soll, befinden sich bereits einige Einträge. Fragliiche Tabelle habe ich von MyISAM in INNODB umgewandelt.

SQL-Befehl:

ALTER TABLE `Rechnungen` ADD  FOREIGN KEY (`LID`) REFERENCES `Lieferanten`(`idLieferanten`) ON DELETE RESTRICT ON UPDATE RESTRICT;

Daraufhin bekomme ich folgende Fehlermeldung:

Fehlermeldung:
#1452 - Kann Kind-Zeile nicht hinzufügen oder aktualisieren: eine Fremdschlüsselbedingung schlägt fehl (d02e82d4.#sql-f73_2c0956, CONSTRAINT #sql-f73_2c0956_ibfk_1 FOREIGN KEY (LID) REFERENCES Lieferanten (idLieferanten))

In einer 2. Datenbank mit ähnlichen Bedingungen war der Fremdschlüssel ohne Probleme zu erstellen.

Ich habe keine Ideen mehr.

Danke für Hilfe

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

87 Beiträge seit 2016
vor 4 Jahren

Hallo,

gibt es in der Tabelle Rechnungen eine Liferanten-ID, die es in der Tabelle Lieferanten nicht gibt?

glandorf

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 4 Jahren

gibt es in der Tabelle Rechnungen eine Liferanten-ID, die es in der Tabelle Lieferanten nicht gibt?

Theoretisch möglich, da immer wieder Lieferanten hinzukommen, gelöscht werden.
Auch wenn es dann die betreffende Rechnung nicht tangiert hatte.

Kann das ein Grund für eine Fehlermeldung sein?

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 4 Jahren

Danke glandorf, hat geklappt. Ein Eintrag korrigiert und Fremdschlüssel erstellt.

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

463 Beiträge seit 2009
vor 4 Jahren

Theoretisch möglich, da immer wieder Lieferanten hinzukommen, gelöscht werden.

ERP Grundkurs 1. Stunde: Du kannst/darfst keine Lieferanten löschen welche in einer Rechnung vorhanden sind..

T
2.224 Beiträge seit 2008
vor 4 Jahren

Zum einen gilt das was Stefan.Haegele sagt zum anderen würde ich zu jeder Rechnung die Lieferanten Informationen gesondert speichern.

Wenn die Lieferanten Tabelle mehr als Stammdaten Tabelle fungiert und häufig Einträge gelöscht/hinzugefügt werden, dann macht es Sinn die Daten zur Rechnung in einer eigenen Tabelle zu speichern aber wie bisher mit Verweis auf den Eintrag.

Also z.B. eine Tabelle Rechnungslieferanten mit den nötigen Informationen des Lieferanten für die Rechnung.
Dann kannst du mit einer Spalte LieferantenID in der Rechnungen Tabelle auf die Rechnungslieferanten Tabelle verweisen.
Somit bleiben deine Daten auch über Jahre hinweg erhalten.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.835 Beiträge seit 2008
vor 4 Jahren

Zum einen gilt das was Stefan.Haegele sagt zum anderen würde ich zu jeder Rechnung die Lieferanten Informationen gesondert speichern.

Das ist der richtige Weg. Nennt sich gewollte Redundanz.

Es gibt dazu auch eine gesetzliche Anforderung, dass sich eine Rechnung (mit gewissen Ausnahmen) nicht verändern lassen dürfen.
Dazu gehört zB. dass Informationen wie Lieferanten-Daten oder Adressen etc sich nicht ändern dürfen.

Hätte man nur eine Referenz von einer Rechnung auf einen Lieferanten, dann könnte man diese rechtliche Anforderung nicht erfüllen.
Denn wenn sich die Lieferanten-Infos ändern, würde sich auch die Rechnung ändern. Das ist nicht erlaubt.

463 Beiträge seit 2009
vor 4 Jahren

Das ist der richtige Weg. Nennt sich gewollte Redundanz.

Das ist vollkommen richtig - aus diesem Grund werden die notwendigen Felder kopiert. Jedoch ändert dies nicht an der Grundaussage, dass bebuchte Datensätze nicht gelöscht werden dürfen/sollten. Denn man kopiert ja nicht alle Daten (hier eines Lieferanten) sondern nur für die Bestellung bzw. rechtlich Vorgaben relevante Felder.

T
2.224 Beiträge seit 2008
vor 4 Jahren

@Stefan.Haegele
Und genau dies hatte ich geschrieben und Abt nochmal bestätigt und sowie begründet warum dies auch in einigen Fällen nötig ist.
Ist also alles in Ordnung 😃

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.