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 alsDISTINCT 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