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
) REFERENCESLieferanten
(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
Hallo,
gibt es in der Tabelle Rechnungen eine Liferanten-ID, die es in der Tabelle Lieferanten nicht gibt?
glandorf
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
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
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..
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.
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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.
@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.