Adressdublettenprüfung

Re: Adressdublettenprüfung

dasistmeinnick11+ — Thu, 19 Nov 2009 12:35:44 GMT

Bindestrich sollte noch bedacht werden

Re: Adressdublettenprüfung

dasistmeinnick11+ — Thu, 19 Nov 2009 12:35:44 GMT

Bindestrich sollte noch bedacht werden bzw. schreibt der eine Gasse/Platz/Straße extra nach einer Leertaste, der andere aber zusammen.

Re(2): Adressdublettenprüfung

Hawelka — Wed, 18 Nov 2009 16:01:36 GMT

Zweiter Schritt: Kölner Phonetik mit menschlichem Interceptor.
(Ansonsten kanns nämlich passieren, dass die Herren Kaumer wohnhaft in der
Küngstrasse mit dem Herrn Kamor wohnhaft in der Keinigstrasse als Dublette
zusammengelegt werden - selber Phonetischer Code..)....

Hi!

Bei der Dublettenprüfung wird es ohnehin so sein, dass es nicht zu einer Hinderung der Anlage kommt, sondern dass lediglich eine Liste mit Treffern angezeigt wird.
Der Anwender kann sich dann für eine etwaige bestehede Adresse entscheiden, oder das Hinweisfenster einfach ignorieren.

Meine Variante ist insofern einfacher, als dass ich das Land/PLZ als Vorselektionskriterium heranziehe. Einach aus dem Grund, weil die PLZ eigentlich immer korrekt ist. Das liegt aber daran, dass nur bereits hinterlegt PLZ/Orte zugelassen werden und nur mit sehr viel Aufwand, eine dem System unbekannte PLZ eingegeben werden kann. Bis auf jene Länder, wo im System kein entsprechender PLZ-Katalog vorhanden ist. Aber das trifft bei diesem Kunden so gut wie nicht zu.

Gruß!
Hawelka

Re(3): Adressdublettenprüfung

Hawelka — Wed, 18 Nov 2009 15:51:24 GMT

Du (Hawelka) solltest die berechneten Felder gleich in der Tabelle mitführen.
Ein paar Vorersetzungen, so wie angeführt, kann man natürlich vor die
Berechnung schalten.

Ich habs jetzt auch so gelöst, dass über einen DB-Write-Trigger die Adressen entsprechend analysiert und codiert werden und das Ergebnis in einer entsprechenden Tabelle indiziert abgelegt werden. Das dauert beim Ändern/Anlegen bloss ein Augenzinkern und der eigentliche Vergleich kann auf bereits fertige Keys losgehen.
Jetzt muss nur noch die Liste mit den Filterphrasen aufgebaut werden

Re: Adressdublettenprüfung

shodan — Wed, 18 Nov 2009 13:00:01 GMT

Ist beides allein nicht wirklich geeignet.

Dein Ansatz findet zu wenige Dubletten. Die Kölner Phonetik ist rein automatisiert ein ziemliches Wagnis, da sie oft dubletten liefert, die gar keine sind.

Mein Ansatz wäre ein 2 - Schritt - Algorithmus.

Erster Schritt: erweiterte Variante deiner Version (über Regex-Ersetzungen) -> Filterung echter Dubletten.

Zweiter Schritt: Kölner Phonetik mit menschlichem Interceptor.
(Ansonsten kanns nämlich passieren, dass die Herren Kaumer wohnhaft in der Küngstrasse mit dem Herrn Kamor wohnhaft in der Keinigstrasse als Dublette zusammengelegt werden - selber Phonetischer Code..)....

Re(2): Adressdublettenprüfung

Xane — Wed, 18 Nov 2009 00:51:44 GMT

Kölner Phonetik

Gutes Stichwort, damit wurde auch bei uns die Dublettenprüfung realisiert.
Mehrere 100.000 Datensätze, Check über mehrere (4?) Felder, Responsezeit < 1 Sekunde, in Wahrheit nur abhängig von der Anzahl der zurückgelieferten Dublettensätze. Ergebnis durchaus brauchbar.

Du (Hawelka) solltest die berechneten Felder gleich in der Tabelle mitführen. Ein paar Vorersetzungen, so wie angeführt, kann man natürlich vor die Berechnung schalten.

Re(2): Adressdublettenprüfung

Xane — Wed, 18 Nov 2009 00:51:44 GMT

Kölner Phonetik

Gutes Stichwort, damit wurde auch bei uns die Dublettenprüfung realisiert.
Mehrere 100.000 Datensätze, Check über mehrere (4?) Felder, Responsezeit < 1 Sekunde, in Wahrheit nur abhängig von der Anzahl der zurückgelieferten Dublettensätze. Ergebnis durchaus brauchbar.

Du solltest die berechneten Felder gleich in der Tabelle mitführen. Ein paar Vorersetzungen, so wie du angeführt hast, kann man natürlich vor die Berechnung schalten.

Re(2): Adressdublettenprüfung

Xane — Wed, 18 Nov 2009 00:51:44 GMT

Kölner Phonetik

Gutes Stichwort, damit wurde auch bei uns die Dublettenprüfung realisiert.
Mehrere 100.000 Datensätze, Check über mehrere (4?) Felder, Responsezeit < 1 Sekunde, in Wahrheit nur abhängig von der Anzahl der zurückgelieferten Dublettensätze. Ergebnis durchaus brauchbar.

Du solltest die berechneten Felder gleich in der Tabelle mitführen. Ein paar Vorersetzung, so wie du angeführt hast, kann man natürlich vor die Berechnung schalten.

Re: Adressdublettenprüfung

j. — Tue, 17 Nov 2009 14:43:50 GMT

Afaik hatte die Pozilei mal sowas sehr gut funktionierend. Da wurde alles beinhart runtergebrochen so wies auch in der Kölner Phonetik passiert.

Re(4): Adressdublettenprüfung

Hawelka — Sun, 15 Nov 2009 12:52:51 GMT

Da bin ich auch voll bei Dir!
Nur ist es so, dass ich diese Erweiterung in eine bestehende Anwendung integrieren soll, welche unter Linux läuft.

Danke!
Hawelka

Re(3): Adressdublettenprüfung

ruprecht69 — Sun, 15 Nov 2009 00:35:01 GMT

Grade dann solltest du wissen, dass man das Rad nicht neu erfinden muß .

Re(3): Adressdublettenprüfung

Paulas_Papa — Sat, 14 Nov 2009 22:42:01 GMT

Ich versuch dir bloß zu sagen, dass diese Problem bereits wirklich gut gelöst ist und du daher dein Hirn über anderen Themen zermartern solltest.

mfg
lukas

Re(7): Adressdublettenprüfung

Capt.Nemo — Sat, 14 Nov 2009 12:30:33 GMT

Also, dies möchte ich bezweifeln. Hast du dir den Algorithmus schon mal näher angesehen?

Nein, wir verwenden das Programm nur, wir entwickeln es nicht

Das würde mir aber nicht viel helfen, da ich ja nicht weiß, welche Methode(n) hier tatsächlich angewendet werden.

War auch nur als Beispiel gedacht, um dir zu zeigen wie Leistungsfähig unscharfe Suche ist (Trefferquote und Geschwindigkeit).

Ja - schon klar, ich wollte damit darstellen, dass überflüssige Begriffe einfach das Ergebnis negativ beeinflussen.

Ja tun sie. Ein paar kann man wegfiltern, aber verschwende nicht zu viel Energie damit. Vor allem, wenn wie du sagst, die Felder nichtmal richtig ausgefüllt werden(!)

Aber die Fuzzy-Suche und ein vorgelagerter Filter schließen sich ja auch nicht aus.

Nein tun sie nicht, siehe oben. Aber ich sage dir aus Erfahrung: Verschwende nicht zu viel Energie damit, du glaubst nicht was es alles für Gemeinsamkeiten gibt, die dann doch keine identen Datensätze sind.

Meine Empfehlung für das Projekt (beruht auf einmaliger Erfahrung, da wir eine minimal größere DB entrümpelt habe):
* Säuberung der DB. Ich weiß, da sind 1 bis 2 Mannjahre nötig (eventuell extern vergeben), aber Adressen sind idR Kapital und das sollte dem MD klar sein.
* Regeln und deren konsequente Umsetzung und Kontrolle bei der Neuanlage oder Änderung von Datensätzen (Schulung der MA die im CRM Ändern dürfen).

Und dann kann dein Programm greifen. Wenn die Daten mal halbwegs strukturiert sind, dann ist eine gut eingestellte unscharfe Suche bei kleineren Tipp- und Eingabefehlern zu 100% treffsicher und liefert nur sehr wenige zufällige Ähnlichkeiten.

Und nochwas: Ein Herr Maier muß kein Meier sein, ein KR G. Huber muß nicht gleich einem Dr. G. Huber sein usw. Bei 20.000 Datensätzen wäre ich mit den von dir vorgeschlagenen Vereinfachungen schon sehr vorsichtig.

Und wie gesagt: Die Geschwindigkeit passt. Außerdem ist es sicher kein Problem, wenn nach dem Button "Speichern" das CRM mal für eine Sekunde eine Gedankenpause macht um die Ähnlichkeiten zu den bereits in der DB angelegten Datensätzen zu berechnen - muß ja nicht live während der Eingabe passieren.

Re(9): Adressdublettenprüfung

-Transformer2K- — Sat, 14 Nov 2009 11:55:31 GMT

was eröffnest dann einen Thread, wennst eh weißt, wie es geht

Re(4): Adressdublettenprüfung

Hawelka — Sat, 14 Nov 2009 11:42:44 GMT

Hab ich zwar schon gefunden - aber danke dafür!

Re(6): Adressdublettenprüfung

Hawelka — Sat, 14 Nov 2009 11:41:42 GMT

Ich weiß ja nicht wie groß die DB ist nach der du abgleichen willst

Die ist nicht besonders riesig - rund 20.000 Adressen, und davon ca. 98% im deutschsprachigen Raum.

EINE Adresse gegen alle in der DB, nicht alle gegen alle) durchzuführen, eine Arbeit von Deinen geforderten Millisekunden

Also, dies möchte ich bezweifeln. Hast du dir den Algorithmus schon mal näher angesehen?

Wie gesagt, lad das Programm mal runter

Das würde mir aber nicht viel helfen, da ich ja nicht weiß, welche Methode(n) hier tatsächlich angewendet werden. Und der Grund für mich, hier zu posten, ist ja nicht, dass ich eine Zusatzsoftware suche, sondern ein paar Ideen zu diesem Thema. Welche du übrigens auch geliefert hast!

Wegen deinem Beispiel: Aus genau diesem Grund gleicht man ja auch den gesamten Datensatz ab (also inkl. Adresse, Tel. Nr, etc.), und nicht nur den Namen

Ja - schon klar, ich wollte damit darstellen, dass überflüssige Begriffe einfach das Ergebnis negativ beeinflussen. Aber die Fuzzy-Suche und ein vorgelagerter Filter schließen sich ja auch nicht aus.

Außerdem sollte eine Software dem Benutzer nicht verbieten

Hab ich auch nicht vor

BTW, der Algorithmus würde nicht A=B ausgeben (dann ist was falsch) sondern eine Ähnlichkeit von xx% von A, B und C.

aber du weißt, was ich damit meinte

Re(3): Adressdublettenprüfung

hellbringer — Sat, 14 Nov 2009 11:19:37 GMT

Der ist mir da ein bissi zu "englisch" orientiert.

http://de.wikipedia.org/wiki/K%C3%B6lner_Phonetik

Re(5): Adressdublettenprüfung

Capt.Nemo — Sat, 14 Nov 2009 11:13:58 GMT

Ich weiß ja nicht wie groß die DB ist nach der du abgleichen willst, aber selbst mehrere tausend Datensätze werden mit dem Programm in wenigen Sekunden Kreuz-Abgeglichen, also sollte es für einen durchschnittlichen heutigen Rechner einen einfachen Abgleich (also EINE Adresse gegen alle in der DB, nicht alle gegen alle) durchzuführen, eine Arbeit von Deinen geforderten Millisekunden sein. Wie gesagt, lad das Programm mal runter (gibt eine Demoversion), exportier deine DB mal, und gleich sie mit einer einzelnen Adresse ab, dann siehst du wie Leistungsfähig das Ganze ist, wenn man es ordentlich Programmiert.

Bezüglich Eignung: Bei Adress-Abgleichen ist eine unscharfe Suche die einzige geeignete Lösung!

Wegen deinem Beispiel: Aus genau diesem Grund gleicht man ja auch den gesamten Datensatz ab (also inkl. Adresse, Tel. Nr, etc.), und nicht nur den Namen. Außerdem sollte eine Software dem Benutzer nicht verbieten den Datensatz anzulegen, sondern eine Auswahl an ähnlichen Treffern präsentieren und den Anwender entscheiden lassen, ob der Datensatz schon vorhanden ist oder neu angelegt wird.
BTW, der Algorithmus würde nicht A=B ausgeben (dann ist was falsch) sondern eine Ähnlichkeit von xx% von A, B und C.

Re(8): Adressdublettenprüfung

Hawelka — Sat, 14 Nov 2009 10:38:47 GMT

Oder halt alle Telefonbücher der Welt importierte und eine Neuanlage gar nicht mehr zulasse

Re(7): Adressdublettenprüfung

-Transformer2K- — Sat, 14 Nov 2009 10:36:32 GMT

tjo dann musst halt die Anwendung so umprogrammieren, dass man bei Straße, Ort und PLZ nur Daten vom Straßenverzeichnis auswählen kann und nur mehr die Hausnummer ein freies Feld ist!

Re(6): Adressdublettenprüfung

Hawelka — Sat, 14 Nov 2009 10:34:16 GMT

sondern die Datenbank selber

Full ACK!
Aber meinst, dass die Anwender das kümmert?
Die schreiben in das Firmenfeld die Personendaten, und wenns mal extrem gut drauf sind, die Personendaten in das Straßenfeld

Re(5): Adressdublettenprüfung

-Transformer2K- — Sat, 14 Nov 2009 10:31:47 GMT

na dann

Re(4): Adressdublettenprüfung

Hawelka — Sat, 14 Nov 2009 10:31:19 GMT

da die Daten einen realen Wert haben, kann ich sie dir nicht einfach so
liefern

War auch nicht so bier-ernst zu verstehen.

Re(5): Adressdublettenprüfung

-Transformer2K- — Sat, 14 Nov 2009 10:29:51 GMT

wenn man die Daten normalisiert abspeichert, können sich solche Fälle erst gar nicht ergeben - soll heißen, dass nicht der Import das Problem ist, sondern die Datenbank selber!

Re(5): Adressdublettenprüfung

-Transformer2K- — Sat, 14 Nov 2009 10:29:51 GMT

wenn man die Daten normalisiert abspeichert, können sich solche Fälle erst gar nicht ergeben!

Re(3): Adressdublettenprüfung

-Transformer2K- — Sat, 14 Nov 2009 10:28:26 GMT

da die Daten einen realen Wert haben, kann ich sie dir nicht einfach so liefern

Re(2): Adressdublettenprüfung

Hawelka — Sat, 14 Nov 2009 10:18:40 GMT

Ich hätte halt soooo gerne mal ein paar Fakten zu diesen Äußerungen

Re(4): Adressdublettenprüfung

Hawelka — Sat, 14 Nov 2009 10:17:04 GMT

Mußt ja ned gleich so angrührt sein

Deine Idee mit der Fuzzy-Logic .. ähhmm Fuzzy-Suche ist ja auch interessant.
Nur für diesen Anwendungsfall einfach ungeeignet.
Unabhängig von der Effizienz, wäre diese Methode schlicht zu rechenintensiv.
Mein Adressenabgleich passiert ja nicht im Stapel mit bereits vorhandenem Datenmaterial, sondern bereits während der Erfassung um schon im Vorfeld Dubletten zu vermeiden.
Der Anwender sollte innerhalb einiger Millisekunden einen Hinweis bekommen, dass Ählichkeiten festgestellt wurden und eine Liste der verdächtigen Adressen erhalten.
Und Adressdaten beinhalten nun mal sehr viele Begriffe, welche einen rein mathematischen Ansatz ineffizient machen.

Ein Beispiel:
A.) Herr Kommerzialrat Dr. Berhard Huber
B.) Herr Dr. Bernhard Meier, Kommerzialrat
C.) Hr. Dr. Bernhard Huber

Ein rein mathematischer Ansatz würde sich für A=B entscheiden, weil hier die größten Ähnlichkeiten vorliegen. Wendet man aber einen Filter an, welcher alle adresstypischen Phrasen wie "Dr., Kommerzialrat, Herr, Hr. ...." herausnimmt, bekommt man eine andere Qualität an Vergleichsdaten.
Mit diesen Restdaten könnte man nun eine Ähnlichkeitssuche durchführen. Aber selbst dann bietet sich eine phonetische Suche eher an, als eine rein stringorientierte.
Die "Kölner Phonetik" scheint hier das deutschsprachige Gegenstück zum "Soundex" zu sein.

Re: Adressdublettenprüfung

-Transformer2K- — Sat, 14 Nov 2009 09:37:09 GMT

na viel Spass, dein Ansatz funktioniert vielleicht bei einer Datenbank mit ein paar Hundert Datensätze, aber wennst mal mit Daten unterschiedlicher Qualität zu tun hast und die betreffende Tabelle mehrere Millionen Einträge hat, wird man dir wohl nicht mal mehr ein müdes Lächeln schenken

Hättet ihr noch weitere oder gar völlig andere Ideen, wie man halbwegs brauchbar (eine 100%-Lösung gibts es hier eh nicht) die Adressen vergleichen könnte?

ja, ohne Fuzzy-Suche gar nicht und da berufe ich mich auf meine Erfahrung mit ca. 20 Mio. Datensätze

Re: Adressdublettenprüfung

-Transformer2K- — Sat, 14 Nov 2009 09:37:09 GMT

Re(3): Adressdublettenprüfung

Capt.Nemo — Fri, 13 Nov 2009 23:58:56 GMT

Fuzzy-Logic

Fuzzy-Suche, nicht Fuzzy-Logic!

kennt weder das "ß"/"ss"-Thema. noch die Tatsache, dass "st." das gleiche wie "strasse" sein kann.

[ ] du hast verstanden was eine unscharfe Suche ist.

Wenn du mir aber verrätst, wie du mit Hilfe der Levenshtein-Distanz bereits eine perfekte Adressdubletten-Prüfung realisiert hast, wo die Anwender alle "ahhhh" gesagt haben, bist mein Held

_Ich_ werd dir sicher nix vorbeten, aus 4 Gründen:
1.) wenn du schon nichmtal Fuzzy-Logic von der Fuzzy-Suche unterscheiden kannst, bezweifle ich dass du
2.) schon jemals etwas von unscharfer Suche gehört hast, und daraus schließe ich dass du keine Ahnung von Programmieren hast, damit ist das Projekt schon zum scheitern verurteilt und
3.) wenn ich es dir vorbeten könnte, würd ich es nicht machen, sondern selber machen.
4.) gibt es das schon. z.B. http://www.dataqualityapps.de/dublettenabgleich.html Exportier mal deine CRM-DB dorthin, probiers aus und staune. Besser als dein angedachter Expertensystem-Krampf ist das Ding auf alle Fälle. Bevor du fragst was ein Expertensystem ist, da du ja keine Ahnung von Programmieren hast: http://de.wikipedia.org/wiki/Expertensystem (aber du bist ja Beratungsresistent, also Programmier fleißig an deinem Stuß weiter).

ad DQT: a) das gibts von mindestens 100 anderen Firmen auch b) Wird damit bei uns bei jeder Aussendung zwischen 100 und 30.000 Adressen abgegelichen -> pfunziwunzifunztatatut perfekt. c) Kostet sogar in der größten Lizenz weniger als 1 Tag Programmieraufwand ... Na gut ... dein Tag wird sicher nicht so viel kosten... d) also kauf das Teil und leg deine Ambitionen wieder schlafen.

........ Wie kann man nur auf die Idee kommen ein Expertensystem für einen Adressabgleich zu verwenden......

Re(2): Adressdublettenprüfung

Hawelka — Fri, 13 Nov 2009 23:25:48 GMT

_das_ (und Derivate) wird für Dublettensuche verwendet, alles Andere ist
elender Murks.

Das mag ja sein, aber hier geht es um Adressdubletten!
Abgesehen von der sehr hohen Rechenzeit, ist dieser Ansatz bei Adressmaterial einfach nicht geeignet.
Wenn jemand "Seifenstein" heisst, wird ihn wohl kaum ein Anwender als "Steinseife" getippt haben.
Außerdem ist eine Adresse feldweise unterschiedlich zu betrachten.
Bei einer PLZ sollte der Buchstabe "O" zu einer Null konvertiert werden.
Während in den Namensfelder Abkürzungen der Titel und Anreden das Problem sind.
Deine vermeintliche Patent-Lösung via Fuzzy-Logic kennt weder das "ß"/"ss"-Thema. noch die Tatsache, dass "st." das gleiche wie "strasse" sein kann.

Wenn du mir aber verrätst, wie du mit Hilfe der Levenshtein-Distanz bereits eine perfekte Adressdubletten-Prüfung realisiert hast, wo die Anwender alle "ahhhh" gesagt haben, bist mein Held

Re: Adressdublettenprüfung

Capt.Nemo — Fri, 13 Nov 2009 22:45:56 GMT

(...) Liste (...) durchgearbeitet (...) werden herausgeschnitten (...) wortweise zerlegt (...) Anzahl der Treffer (...)

Falscher Ansatz!

http://de.wikipedia.org/wiki/Fuzzy-Suche

_das_ (und Derivate) wird für Dublettensuche verwendet, alles Andere ist elender Murks.

Re(2): Adressdublettenprüfung

Hawelka — Fri, 13 Nov 2009 21:50:51 GMT

Gratis Demo!

Eh, aber ich bin selber SW-Entwickler

Re: Adressdublettenprüfung

Paulas_Papa — Fri, 13 Nov 2009 21:31:42 GMT

http://www.omikron.net/Dubletten-Bereinigung.html?dq=AdWords&gclid=CP3K94L2iJ4CFUOFzAodH0qLqA

Gratis Demo!

mfg
lukas

Re(2): Adressdublettenprüfung

Hawelka — Fri, 13 Nov 2009 18:37:28 GMT

Bevor man sich nicht mit sowas beschäftigt hat, ahnt man ja nicht einmal, wie viele Schreibweisen es geben kann.

Das hat auch so was menschliches, find ich
Eine Adresse und 5 Schreibweisen

Mir hat damals auch der Soundex-Algorithmus weitergeholfen.

Der ist mir da ein bissi zu "englisch" orientiert.

Re: Adressdublettenprüfung

Robert Craven — Fri, 13 Nov 2009 17:12:06 GMT

So eine Anwedung hab ich auch schon mal programmiert. Bevor man sich nicht mit sowas beschäftigt hat, ahnt man ja nicht einmal, wie viele Schreibweisen es geben kann.
Im Prinzip war mein Ansatz ähnlich. Also die häufigsten Unterschiede auf eine gemeinsame Schreibweise bringen, und dann vergleichen. Ausreichend idente Einträge automatisch löschen, den Rest eben nach Ähnlichkeit sortiert ausgeben für die händische Überprüfung. Mir hat damals auch der Soundex-Algorithmus weitergeholfen.
100% korrekt und 100% automatisiert gings bei mir aber natürlich auch nicht.

Adressdublettenprüfung

Hawelka — Fri, 13 Nov 2009 16:24:42 GMT

Hi,

habt ihr euch mit dem Thema schon mal beschäftigt?

Meine Ideen dazu:
Die Basis muss mal das Land und die PLZ sein. Es werden also nur Adressen geprüft, wo diese beiden Felder mit der neu anzulegenden exakt übereinstimmen.

Dann könnte eine Routine die neue und alle mit dem Land/PLZ übereinstimmenden Adressen "verdichten", in dem eine Liste mit Phrasen durchgearbeitet wird.
D.h.: Alle "Dr.,Doktor,Mag.,Fr.,Hr.,Ing., ....." werden mal herausgeschnitten.
Weiters:
- Alle Doppelbuchstaben werden zu einzelnen.
- Alle "ph" werden zu "f"
- Alle "ai" und "ey" werden zu "ei"
- Alle "ß" werden zu "s"

Im Strassenfeld:
- Alle "str." und "straße" werden zu "strasse"
- Alle "pl." werden zu "platz"
- Alle "g." werden zu "gasse"
- Alle "/" werden zu blanks

Danach:
wird jedes Feld jeder Adresse wortweise zerlegt und in eine temporäre Tabelle abgelegt.

Zuletzt wird die Anzahl der Treffer zwischen der neuen und jeder bestehenden Adresse aus der temporären Tabelle ermittelt.
Die Summe der Treffer ergibt dann das Ranking der Vorschlagsadressen welche verdächtig ähnlich sind. Wobei hier dann auch eine Grenze einzuziehen wäre. Z.Bsp. Adressen unter n Treffer kommen gar nicht in die Liste der möglichen Dubletten.

Hättet ihr noch weitere oder gar völlig andere Ideen, wie man halbwegs brauchbar (eine 100%-Lösung gibts es hier eh nicht) die Adressen vergleichen könnte?

Gruß!
Hawelka