Das deutsche Python-Forum

Hallo Leute,

ich habe mal wieder ein ganz besonderes Problemchen:

Ich update auf ein Feld in welchem ich ein UNIQE gesetzt habe (-> Secondary Key).
Es gibt jedoch eine kleine Fehlerquote von ca. 0,001 % welche mich veranlasst hat den UPDATE mit dem Zusatz IGNORE auszuführen (ich manage die Fehler vorerst nachfolgend manuell).
Den Fehler kann ich nicht ausbügeln da die Daten per BeutifulSoup von extern geparsed werden und ich kein Administrator dieser Daten bin.

Ich würde jetzt folgendes haben wollen und frage euch ob das geht und wenn ja wie:
Kann ich dem UPDATE IGNORE-Vorgang auch sagen: bitte wenn du auf diesen Fehler läufst, tue den aktuellen Datensatz nicht nur NICHT UPDATEN sondern update mir das SK-Feld 'match' von 1 auf 0?
(Feld besagt ob ein Treffer (= match) vorhanden ist (=1) oder nicht (=0)).

Ich könnte auch vorher abfragen ob bereits ein Match vorhanden ist, aber die Daten befinden sich bereits in meiner DB in einer 'sekundären' Tabelle und ich habe eine irre lange SQL-Abfrage erstellt mit > 15 JOINS und echt komplex welche den UPDATE von sekundäre Tabelle auf primäre Tabelle entsprechend des Matches ausführt. Ich würde ungern so eine DIN A2-große SQL einmal ausführen um zu prüfen ob es bereits ein Eintrag gibt und wenn nein einfach updaten und wenn ja dann irgendwas zu unternehmen was mir den Matchstatus des bereits in der DB befindlichen Datensatzen up zu daten.

Ich dachte vielleicht gibt es ein anderen Befehl statt des IGNORES welcher mir die Arbeit abnimmt? Oder eine andere Heransgehensweise die ich bisher nicht kenne mit Stored-Procedure und Trigger im Fehlerfall o.ä.?

@kaineanung: ein SQL-Abfrage mit 15 joins sieht mir nach falschem Datenbankdesign aus. Was und wie möchtest Du denn UPDATEn und warum gibt es „Fehler“?

@Sirius3

Naja, falsches Datenbankdesign ist es nicht (meiner Bescheidenen Meinung nach).
Aber um diesen 'Match' zu finden, wobei die externen Daten mit meinen Daten 'gematched' werden, muss ich alle Informationen miteinander Vergleichen um eine höchst genaue Zordnung der Datensätze zu finden.

Nehmen wir einmal ein Fußballspiel als Beispiel:
um die Spieler beider Quellen miteinander zu matchen, und dabei nicht über den Namen gehen zu müssen (höchst ungenau und viele doppelte Namen),
muss ich alle Spieltagdaten, Auswechslungen, Spielzeiten, Tore, Karten, Ein- und Auswechslungen, Zeitpunkte dieser usw. holen. Dann sind die Spieler ja ihren Teams zugeordnet. Also joinen. Dann sind diese Teams Ligen und Saisons zugeorndet, also 2x Join, dann sind diese Ligen Ländern zugeorndet. Nochmals ein Join. Dann das alles für beide Quellen und dann die fertigen Sets nocheinmal untereinander verknüpft.

Jetzt bekomme ich bei jedem Datensatz einen eindeutigen Treffer. Alle Anderen sind im Set nicht vorhanden -> kein Match und müssen manuell Verknüpft werden. Diese Vorgehensweise ist erstaunlich genau und es bleiben sehr wenige Daten 'nicht gematcht'.

So, in meinem Fall sind das andere Daten, aber ähnlich komplex und ähnliche viele Tabellen die ich joinen muss. Und da ich mich gefühlt an eine 2,5te Normalform gehalten habe beim Design der DB, habe ich in diesem speziellen Fall eben mehr als 15 Joins. Nachdem neue Daten hereingeholt wurden läuft das Matchen einmal durch und danach brauche ich es in 'Echtbetrieb' ja nicht mehr. Daher denke ich das mein Design der DB durchaus 'normal' ist.

Ach ja, und die 'übergeordneten' Daten sind bereits gematched -> obiges Beispiel: ich will Spieler matchen und und nutze bereits gematchte Tabellen der Ligen, Länder, Teams, usw.)
Die haben eine 'Auflösungstabelle' (eigene PK, externe PK) auf die ich Joine, die wiederrum mit dem Pendand in der anderen Tabelle gejoint werden.
Somit sind ganz sicher viele Joins vorhanden, aber das DB-Design der zugehörigen Tabellen (also die meiner eigenen Tabellen und die der externen Daten) sollten einer 3-Normalform entsprechen. Da ich mir an manchen Stellen das Leben einfacher machen wollte, gibt es den einen oder anderen Datensatz der doch eine redundante Information enthält. Aber wir reden von 2-3 Tabellen die doch noch einen Key beinhaltet welcher z.B. in der Auflösungstabelle 'hergejoint' hätte werden können. Daher 2,5te Normalform.

Aber jetzt zu meiner Frage:
gibt es eine Vorgehensart oder einen Befehl der besagt daß wenn ein UPDATE eintritt und der UNIQUE-Index diesen verhindert, eben nicht nur ignoriert wird sondern das etwas gemacht wird wie z.B. den Datensatz, welcher diesen UNIQUE-Index bereits besitzt, manipuliert werden kann (geupdatet)?