..."Der entscheidende Schritt ist ja wohl
ein Normalisierungsverfahren, das auf beiden Seiten identisch eingesetzt wird."...
Genau darum werden auch bereits bekannte & validierte eigene Adressen durch die gleiche Prozedur wie unbekannte/neue Daten geschickt...
=> resultierender Trick ist die sich so ergebende Möglichkeit eines anschließenden simplen 1:1 Hash-Vergleichs, welcher sich dann so auf ein konstantes (internes)Datenformat XY bezieht...
..."Warum man dazu unbedingt den (vorsichtigen) Missbrauch von irgendwelchen öffentlich verfügbaren Schnittstellen empfehlen muss, leuchtet mir nicht wirklich ein."...
1. Üblich sind ja phonetische oder sonstige unscharfe Vergleiche... nur warum soll man die selbst wiederholt machen?
Die erwähnte Möglichkeit, sowas sagen wir bis zu 1440Abfragen/Tag (=eine pro Minute) zu machen ist einfach ein realer Erfahrungswert.
Wer mehr will, kauft sich per
API-Key eintsprechend viele Abfragen zur Google Maps
API, da kommt dann PLZ, Strasse und Hausnummer immer im gleichen Format raus, egal was man reinsteckt... man nutzt also stat Phonetik-Vergleichstool XY die Google-KI. Zu mehr wie PLZ, Ort & Straße(!ohne Hausnummer!) wird auch die Address-Suche via "DasÖrtliche" oder "GelbeSeiten" nicht genutzt, so stört es schlicht nicht wenn jemand im Telefonbuch steht, solange "irgendjemand" in der Straße noch drin steht
2. wenn ein sagen wir guter "unscharfer Phonetik-Vergleich" ergibt, ja ist zwar nicht exakt "gleich", aber ausreichend "ähnlich"... dann hat man zwar die Info das es kein neuer Datensatz ist, weiß aber dennoch nicht ob nun die "Altdaten" oder die "NeuDaten" näher an der Realität sind... wer die Rechenzeit für so Vergleiche ständig investieren will, für den das mag jetzt reichen... aber spätestens wenn nicht nur langzeitkonstante 2..3 Datenquellen zu matchen sind, fehlt dem Konzept dann eben doch die Normalisierungsstufe(wenigstens intern beim Vergleich)
3. Eine (zusätzliche) eigene exakte Adressvalidierung(im wortwörtlichen Sinn, also "nur" PLZ+Ort+Straße/Postfach) ist schonmal die halbe Miete bei der Erkennung&Trennung der Kontaktdaten(Titel/Person/Firma/Kommunikation(Tel,Fax,Telex,Mail,Facebook,WhatsApp ,Twitter,...) von der Anschrift. Und zur anschließend einfacheren brauchbaren Trennung der reinen Kontaktdaten haben sich eben praktisch zufällig gute "BusinessCardScanner" bewährt, denn genau dafür wurde deren Software scheinbar optimiert.(reine Anschriftsdaten erkennt&trennt die GoogleKI besser)
Wer das per CLI seinem
SQL Server beibringen kann, der soll es tun und sich einer voll offline fähigen und unendlich skalierbaren Lösung erfreuen. Rein praktisch, sagen wir eifach bis 1x pro Minute kann man es online auch mit freien Quellen lösen. Wer schneller mehr braucht, hat einen kommerziellen Grund der auch den Zugriff auf bezahlte APIs(z.B. Google) rechtfertigt.
(für einen kleinen Webshopbetreiber, der meine Lösung einstetzt hatte die "1x pro Minute Regel" sogar den Vorteil, dass so ein Bot-Angriff mit sehr vielen Neuanmeldungen in sehr kurzer Zeit quasi ohne Folgen blieb, denn es gab schlicht nur max. Accountbestätigung(per Mail) pro Minute... da verlor der Bot schnell das Interesse)