Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Algorithmen, Datenstrukturen und Klassendesign (https://www.delphipraxis.net/78-algorithmen-datenstrukturen-und-klassendesign/)
-   -   Adressen abgleichen (https://www.delphipraxis.net/196705-adressen-abgleichen.html)

mensch72 12. Jun 2018 03:37

AW: Adressen abgleichen
 
..."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 12. Jun 2018 06:34

AW: Adressen abgleichen
 
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.

Jasocul 12. Jun 2018 07:30

AW: Adressen abgleichen
 
Erstmal Danke für die vielen Anregungen und Links.

Jobo hat das schon richtig verstanden.
Eine "Korrektur", bzw. Normalisierung der Adressen wird nicht gemacht. Es geht nur um die Feststellung, ob der Kunde des Kunden auch unser Kunde ist. Diese Feststellung wird natürlich festgehalten, wodurch eine erneute Prüfung entfällt.

Natürlich werden diverse Stati festgehalten, die den täglichen Prüf-Vorgang beschleunigen. Bereits geprüfte Daten müssen schließlich nicht nochmal geprüft werden (Sonderfälle mal ausgenommen). Aber das hat ja mit der eigentlichen Prüfung nichts zu tun.

Inzwischen wurde das Projekt "entschärft". Es brennt mir also nicht mehr so sehr unter den Nägeln. Trotzdem würde ich eine Lösung anstreben, bei der ich auf existierende Bibliotheken, Methodensammlungen, etc. zurückgreifen kann. Dafür gab es ja auch schon Hinweise.


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:27 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz