Adressen abgleichen

[stahli]

Wir hatten so etwas hier schon mal: https://www.delphipraxis.net/154811-...rozentual.html

Ich habe noch eine Variante, die Adressen mit "c/o" in die Teile davor und danach zerlegt und diese beide getrennt vergleicht.

Welche Methode zu den eigenen Daten am besten passt musst man immer individuell entscheiden.

[EarlyBird]

vielleicht hilft Dir fuzzydupes-net weiter.
Eventuell kannst Du es direkt in der MS-SQl Datenbank einbinden Stichwort CLI integration.
Ist nicht für Delphi, aber eventuell einen Blick wert

[mensch72]

unabhängig davon ob es ne fertige Fix&Foxi Lösung gibt, wäre es auch da sinnvoll und nötig das Problem zu splitten und zunächst für eine "eineindeutige" Identifizierung/Unterscheidung der täglich gelieferten (nur teils neuen) Daten zu sorgen.

=> 1. grobes Stichwort wäre also ein "Hash" über die "Eingangs-Adressdatensätze", zunächst völlig egal was da drin steht. Es hat sich bewährt, vor dem "CalcHash" zunächst alle WhiteSpaces zu entfernen, dann stören ev. Leerzeichen/Tabulatoren/Zeilenumbrüche welche nur der Formatierung dienen nicht den HashAlgo... wenn Hash erkannt, also Daten 1:1 schonmal erhalten und "ein geprüftes Ergebnis" bekannt, dann stets keine weitere aktive Verarbeitung mehr nötig!

=> 2. grobes Stichwort wäre "grobe" Adresszerlegung, wir "malen" hierzu die Daten einfach der Reihe nach in ein Bitmap, welches quasi einer "Visitenkarte" entspricht... und schau einer guck, da gibt es sehr viele und wirklich gute super Tools, welche bei guten BusinessCardScannern oft gratis dabei sind... wir haben uns da ein Interface "gebastelt", welches einem guten Tool statt Scandaten unser erzeugtes Bitmap unterschiebt und das zerlegte und quasi auch schon normalisierte Resultat "irgendwie" abgreift

=> 3. grobes Stichwort wäre dann "grobe" Adressvalidierung, wir nutzen hierfür Google&Yahoo(ohne Maps???-Api)... einfach die Eingangsdaten ohne Zeilenumbruch ins Suchfeld und dann geschaut was "ähnliches"(!incl. Werbung!) auf der ersten Antwortseite auftaucht... so ist dann zu 97% PLZ & Ort voll validiert&normalisiert... Straße zu 95%, Hausnummer aber nur zu 85%

=> 4. grobes Stichwort wäre bei Bedarf also eine weitere detailierte&automatisiere Adressvalidierung für Straße und Hausnummer... wir nehmen hier eine API für eine bekannte TelefonbuchCD und testen da "vorwärts wie rückwärts Suche", was wir anschließend wenn möglich noch über "DasÖrtliche" gegenprüfen. (man sollte die öffentlichen WebSeiten der "GelbenSeiten" und DasÖrtliche" aber nicht "erkennbar"(zu häufig/zu schnell) für sowas missbrauchen, denn deren Server mögen das nicht und es verstößt klar gegnen deren AGBs!)


Nun hat man im Prinzip Vergleichbares... ABER NUR, wenn man seine eigenen Daten (obwohl eigentlich schon valide) auch nochmal durch den gleichen Ablauf schickt !!!
Abschließend also wieder alle WhiteSpaces heraus und nochmal jeweils einen HashAlgo darüber anwenden. Der jetzt resultuierende Hashvergleich wird nun zu 98+% exakt sein
Den Hash der Eingangsdaten also samt TimeStamp und Hash dieser Ergebnisdaten so speichern, das dies zukünftig Anfangs schnell abprüfbar ist.
Die resultierenden Klartextdaten in einem typisierten internem Standardformat halten und künftig z.B. via JSON,XML,... normiert&standardisiert abfragbar gestalten.


-> interne oder externe Fertiglösungen gibt es stets nur jeweils für Teilbereiche, selbst wenn gute "BusinessCardScanner" quasi den kompletten "logischen" Workflow können, braucht es für den jeweils praktischen Workflow doch stets ein paar Zeilen Programmcode und etwas Hirnschmalz

[jobo]

Na da freu ich mich doch wieder mal, dass ich nicht im "Örtlichen" stehe.

M.E. ging es nicht um Validierung, sondern um Dublettenfindung bzw. Matches.
Dafür ist eine Validierung nicht nötig. Wenn bspw. ständig falsche Daten irgendwo gekauft werden (und importiert und weiterverarbeitet werden), macht es eine zusätzliche Validierung (die gegen unterschiedliche Optimierungsstände läuft) nur bedingt besser, oder?

Der entscheidende Schritt ist ja wohl ein Normalisierungsverfahren, das auf beiden Seiten identisch eingesetzt wird.

Warum man dazu unbedingt den (vorsichtigen) Missbrauch von irgendwelchen öffentlich verfügbaren Schnittstellen empfehlen muss, leuchtet mir nicht wirklich ein.

[p80286]

Zitat von jobo:

M.E. ging es nicht um Validierung, sondern um Dublettenfindung bzw. Matches.

MMMmmm,
was ist eine Doublette?
Manfred Müller, Kaiserplatz 8, Aachen ist wahrscheinlich doppelt, bei
Manfred Müller, Templergraben 55,Aachen wäre ich mir nicht so sicher.
Wenn dann noch abweichende Post- und Hausanschriften ins Spiel kommen kommt man mit dem formalen Ansatz
wenn gültige(Adresse1)=gültige(Adresse2)
nicht sehr weit. So müßten z.B. Anschriften von größeren Organisationen "normalisiert" werden. (abweichende Post und Hausanschrift) und bei Unternehmen die mehre Standorte haben sind diese auch gegen die Zentrale zu vergleichen.(z.B. BASF AG/BASF SE)

Gruß
K-H

[mensch72]

..."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)

[jobo]

Ich habe den TE bzw. den notwendigen Ablauf so verstanden, dass er nur matchen muss und keine Änderungen an den Adressen vornimmt. Das Ergebnis einesAbgleichs wäre Kunde x von unserem Kunden a ist auch|nicht unser direkter Kunde.
Aber das wird der TE sicher selbst am besten wissen.