Folgende Situation:
Wir haben in unserer Datenbank die Adressen unserer Kunden. Soweit nichts ungewöhnliches.
Außerdem stehen in der DB auch die Adressen der Kunden unserer Kunden. Diese werden in der Regeln von unseren Kunden geliefert.

Jetzt kann es passieren, dass der Kunde eines Kunden gleichzeitig auch unser Kunde sein kann.
Das wird von uns durch spezielle Algorithmen geprüft und im Zweifel manuell nachgeprüft und festgehalten.
Bis dahin alles kein Problem.

Durch eine Firmenzusammenführung, bekommen wir jetzt aber täglich Daten aus einem anderen System, die wir nicht durch diesen Algo schicken können. Erklärungen, warum das nicht geht, spare ich mir.
Für diese zusätzlichen Daten, soll ebenfalls festgehalten werden, ob ein Kunde eines Kunden, gleichzeitig Kunde bei uns ist. Da dieser Zustand im anderen System nicht festgehalten wird, geht das nur über einen Adressen-Abgleich bei den gelieferten Daten. Was man bei Adressen alles unterschiedlich oder falsch eingeben kann, ist wohl jedem klar (Phonetik, Abkürzungen, Tippfehler, Wort- und Buchstabendreher, ...).

Der Abgleich muss täglich neu gemacht werden. Natürlich nur für die Adressen, die noch keine Zuordnung haben.

Sicher wäre es mir möglich, so einen Algorithmus zu entwickeln, aber zum Einen will ich das Rad nicht neu erfinden, zum Anderen brauchen wir die Lösung einigermaßen zeitnah.

Nun zur Frage:
Gibt es bereits passende Komponenten oder Methodensammlungen, die das können? Bisher habe ich nur fertige Programme dazu gefunden, aber wir müssen das in unsere täglichen Abläufe integrieren und beeinflussen können. Das kann mit fertigen Anwendungen problematisch werden.

Harte Fakten wären wohl Adressgleichheit und (Tele)Phone Nummer (mit Ungenauigkeit)
Dann Ansprechpartner, ggF. auch Firmenname (sofern aktualisiert nach Zusammenführung, aber wer weiß das schon).

Für den ungenauen Vergleich bieten sich phonetische Algos und sowas wie levenshtein Distnanz an. Ich würde die Vergleiche je Informations Gruppe laufen lassen und Ratings bilden. Dann testen und Schwellwerte für eine "Dublette" definieren.

Ein anderer Ansatz wäre die Nutzung von "normalisierten" Vergleichsfeldern.
Jede Adresse bekommt ein Suchfeld, dass nach einem festen Algorithmus die ersten N Zeichen verschiedener Kennfelder aufnimmt und dabei phonetische -, Steuer-Zeichen und klassische Abkürzungen vereinheitlicht und alles auf Kleinschreibungstellt, u.U. einfach durch weglassen (GmbH, z.Hd., Fr., Frl., Mr. ....)

Hilfreich ist für sowas natürlich eine DB, die solche Algos / Collations schon implementiert hat, sodass nicht alles im Client durchgenudelt werden muss.

Zitat von Jasocul:

Folgende Situation:
Sicher wäre es mir möglich, so einen Algorithmus zu entwickeln, aber zum Einen will ich das Rad nicht neu erfinden, zum Anderen brauchen wir die Lösung einigermaßen zeitnah.

Nun zur Frage:
Gibt es bereits passende Komponenten oder Methodensammlungen, die das können? Bisher habe ich nur fertige Programme dazu gefunden

MailCom (https://adress-designer.de/) hat früher die Komponenten die diese in eigenen Programmen verwenden, einschließlich Delphi Header/Bindings und die notwendigen Referenzdaten verkauft. Einfach mal anrufen ob das noch möglich ist.

Sonst fällt mir nur eine gute (Teil) Komponente ein. Falls Du Postgres verwendest oder verwenden kannst, gibt es für die Adressnormierung "libpostal" (https://github.com/openvenues/libpostal), das ist zwar kein vollständiges System, aber eine sehr wichtige Komponente davon. Libpostal funktioniert gut, sowohl mit deutschen, wie auch mit nichtdeutschen Adressen. Einen (englischer) Blogpost darüber findest Du beispielsweise hier (https://medium.com/@albarrentine/sta...2-80405b988718)

cu Ha-Jö

Danke für die Tipps, jobo.
Die sind mir alle bekannt. Ich könnte das auch sicher selbst alles umsetzen aber dafür fehlt mir einfach die Zeit. Deswegen fragte ich nach fertigen Komponenten / Methoden-Sammlungen.

Eingesetzte DB ist übrigens MS-SQL.

@hanvas:
Danke, ich werde mir das mal ansehen.

Ok, Levensthein und diverse "fertige" phonetische Algorithmen wirst Du sicher in MSSQL finden.
Wenn es noch fertiger sein soll und libpostal helfen würde, dann hilft dir dieser Wrapper vielleicht zur Einbindung direkt in MSSQL:
https://github.com/AeroXuk/LibPostalNet

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.

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

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

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.

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