Fehlerhaften ForeinKey finden

[Perlsau]

Zitat von mensch72:

Ein "on delete cascade" wird es in meinen Anwendungen nicht geben. Dort sollen die Exceptions fliegen, wenn wer was zu löschen versucht, was noch anderswo in Benutzung ist. Wenn überhaupt mache ich das per Triggerfunktion, wo dann StepByStep mit voller Absicht alles einzeln gelöscht wird/werden muss.

In der Anwendung, um die es hier ging, erscheint eine Meldung, wenn der Anwender z.B. einen Ort zu löschen versucht, der bereits mit einer Adresse verknüpft ist: "Dieser Ort kann nicht gelöscht werden, weil derzeit 5 Adressen mit diesem Ort existieren."

Wie oben bereits berichtet, entstanden durch das Einlesen von "unordentlichen" Listen Orte mit unterschiedlichen Schreibweisen, aber gleichen Postleitzahlen. Das ließe sich nur vermeiden, wenn man die Listen vor dem Einlesen manuell am Editor durchforstet, und das wäre ja wohl der Gipfel der Zeitverschwendung ... und der zermürbenden Arbeit ...
Diese Listen müssen von mir nur einmal eingelesen werden, der Anwender bearbeitet die Datenbank-Einträge dann per Hand ... so viele neue Firmen werden in dieser Branche nicht ständig gegründet und beim Anwender angemeldet, daß er das nicht manuell bewältigen könnte. So kann er dann prüfen, ob der Eintrag korrekt ist, die Firmendaten stimmen usw. Die Listen, die ich einmalig einlese und oberflächlich verifiziere, sind dagegen in einem Zeitraum von zig Jahren entstanden.

Zitat von mensch72:

Ein "on update cascade" ist bei mir das einzige, was ich "notfalls" im SingeUserMode für Admins zulasse. Es passiert im Alltag, das mal Artikelnummern "auf die schnelle" von irgendwem angelegt werden, aber derjenige übersieht das es eigentlich eine Struktur gibt, wo sagen wir 1xxxyyyyyy doch was anderes ist wie 2xxxyyyyyy... Anwender sind manchmal kreativ beim einbauen und erfinden von eigenen Zusatzregeln... um sowas dann "in einem Rutsch" zu ändern, so das es sich automatisch auf die gesamte DB auswirkt, egal wo etwas mit diesem Datensatz zu tun hat, genau dafür ist dann ein "on update cascade" brauchbar, aber nicht als Standard. Per Default lasse ich das DBMS eine Execption schmeißen, wenn jemand versucht "Verknüpfungsdaten" einfach so zu ändern.

Genau so macht man das

Daß das Thema hier trotz bereits erfolgter Problemlösung ständig weitere Kommentare erhält, die meinem Empfinden nach einer teilweise fragwürdigen Intention geschuldet sind, hat mich ein wenig verwundert ... nur ein wenig deshalb, weil das hier im Grunde täglich zu beobachten ist.

[Dejan Vu]

Was hier versucht wurde, nennt sich 'Recording Linking' oder einfacher 'Deduplizierung'. Eigentlich ist der Prozess viel komplexer, Perlsau hat die Vorarbeit implizit durch die Orte-Tabelle schon geleistet.

Hier wäre folgende Vorgehensweise sinnvoll gewesen:
Im ersten Schritt werden Duplikate erkannt und verknüpft. z.B. über eine Link-Tabelle. Im zweiten Schritt kann man die Duplikat-IDs in der referenzierenden Tabelle durch die Original-ID ersetzen. Im letzten Schritt können dann die Duplikate sicher entsorgt werden.

Natürlich ersetzt das nicht die notwendige Sicherstellung der referenziellen Integrität durch entsprechende Constraints.

[Hansa]

Zitat von Perlsau:

Daß das Thema hier trotz bereits erfolgter Problemlösung

Wo ist das Problem denn gelöst ? Im Nirwana ! Es sei denn für einmalige Aktion. Rumgefummel an Datenbank.

Nun denn, dann eben One-Man-Show und Perlsau ist kurz glücklich bis zum nächsten Crash.

Zitat:

1xxxyyyyyy doch was anderes ist wie 2xxxyyyyyy... Anwender sind manchmal kreativ beim einbauen und erfinden von eigenen Zusatzregeln... um sowas dann "in einem Rutsch" zu ändern, so das es sich automatisch auf die gesamte DB auswirkt, egal wo etwas mit diesem Datensatz zu tun hat, genau dafür ist dann ein "on update cascade" brauchbar, aber nicht als Standard. Per Default lasse ich das DBMS eine Execption schmeißen, wenn jemand versucht "Verknüpfungsdaten" einfach so zu ändern.

Man nehme zum kompletten Datensalat dann noch die sogenannte "sprechende Artikelnummer", wie Mensch72 anführt. Im Textilbereich immer noch verbreitet. D.h. Ich packe alle Informationen, die ich brauche in eine Artikelnummer, anstatt in Datensatz-Felder (Standard ca 1950er Jahre). Die angesprochenen xxx in 1xxxyyyyyy steht dann z.B. für Textilgrösse 036. yyyyy z.B. für "rot" und dann lässt man den Enduser da rumwurschteln nach Belieben. Die EAN/Art.-Nr., z.B. 1234567890123 steht natürlich auch noch drin. Und fertig. Dann sind für ein 5 EUR T-shirt 20-30 Zeichen zur Warenerfassung nötig. Aber die führenden Nullen für die Grösse nicht vergessen ! Oder dem Programmierer mitteilen, dass meistens die führende 0 vergessen wird ! Na denn viel Vergnügen.

[Dejan Vu]

Das Problem ist imho dadurch gelöst, das:
1. Ein Foreign Key Constraint angelegt wurde bzw. beim nächsten Mal angelegt wird.
2. Auf 'Record Linkage' und 'Deduplication' verwiesen wurde, da es sich um ein Standardproblem handelt.

Desweiteren geht es hier nicht um das Anti-Pattern 'Sprechende eindeutige Werte sind gleichzeitig PK'. Nebenbei: Man kann in seiner Artikelnummer soviel kodieren, wie man möchte, nur darf man diese NIE NIE NIEMALS als PK verwenden. Als PK eignet sich !nur! eine anonyme ID, die keine Sau interessiert, die man nie sieht, über dessen Aussehen sich niemand aufregt und die einfach nur eine ID ist. Mehr nicht. Ein AutoInc ist dafür geeignet, oder eine GUID oder was weiß ich. Aber *KEINE* Artikelnummer.