AW: Fehlerhaften ForeinKey finden
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. |
AW: Fehlerhaften ForeinKey finden
Zitat:
Nun denn, dann eben One-Man-Show und Perlsau ist kurz glücklich bis zum nächsten Crash. Zitat:
|
AW: Fehlerhaften ForeinKey finden
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz