Jörg: sql: Noch ne Nachfrage

Beitrag lesen

Hallo Rolf,

das sind deine Daten und deshalb solltest Du darüber auch den Überblick haben.

Stimmt. 😉

Meine Fernhypothese wäre: In TableK sind zu einer KundenId mehrere Sätze mit unterschiedlicher Kundennummer und/oder Straße. Deswegen liefert DISTINCT id, nummer, straße mehr Rows als DISTINCT id.

Nein, das ist so nicht. Kundenid und Kundennummer sind beide unique. Kundenid ist in tableK "primary Index", Kundennummer ist unique. Einzig in Tabelle tableM könnten mehrere identische Kundennummern oder Ids auftauchen.

Die Query

SELECT xy.Kunden_ID, COUNT(*)
FROM (SELECT DISTINCT  Kunden_ID, Kundennummer, straße
      FROM tableK) xy
GROUP BY xy.Kunden_ID
HAVING COUNT(*) > 1

sollte Dir die IDs liefern, für die das der Fall ist.

MySQL lieferte ein leeres Resultat zurück (d.h. null Datensätze). (Die Abfrage dauerte 0.0211 Sekunden.)

Was mich zu der Frage führt: Warum Kunden_ID und Kundennummer? Reicht die Kundennummer nicht als eindeutiger und unveränderlicher Key? Hast Du eine Vorgabe, dass fachliche Attribute keine technischen Keys sein dürfen? Es ist jetzt sicherlich zu spät, um das zu ändern, aber neugierig bin ich schon.

Ja, diese Vorgabe habe ich selber an mich erteilt. Spaß beiseite, das lag schlicht daran, dass ich je nach Kunde Kundennummern aus altbeständen importieren musste und nicht alle waren "sauber". Damit aber gem. Kundenvorgabe dieser etwas zeit hatte, seinen Kundenstamm sukzessive zu bereinigen, benötigte ich einen eigenen unique Index und konnte erst später die Kundennummernspalte "unique" machen.

Jörg