Aha in turn! https://web-beta.archive.org/web/20101216062156/http://blog.donnael.com:80/2...
On Apr 12, 2017 4:19 PM, "Ted Roche" tedroche@gmail.com wrote:
Ah! The algorithm rang a bell!
Garrett: have you tried searching Archive.org? A LOT of your stuff appears archived: https://web-beta.archive.org/web/*/garrett%20fitzgerald%20
The equivalent FoxPro code, by the way is in the leafe downloads at https://leafe.com/dls/vfp. Bob Calco wrote it up.
Also on Fox Wikis at: http://fox.wikis.com/wc.dll? Wiki~LevenshteinAlgorithm
Craig Boyd's blog about Spell Checking at http://www.sweetpotatosoftware.com/spsblog/CommentView.aspx?guid= 8800bdb9-a9c2-484f-942f-6a08947d903a
On Wed, Apr 12, 2017 at 3:31 PM, Garrett Fitzgerald sarekofvulcan@gmail.com wrote:
I wrote a FLL to do Levenshtein distances for fuzzy name matching, but everything was posted to my blog, which is no longer online. It wasn't amazingly hard to figure out, though, so it might be worth finding the algorithm in C and recreating my steps. It ran much faster than
equivalent
Fox code did.
On Wed, Apr 12, 2017 at 12:49 PM, Stephen Russell <srussell705@gmail.com
wrote:
I remember this joy of searching names in a system that had 2+ million customers and names were all varchar() instead of a key to a secondary table. My indexes sure took a beating when I got another "Williams",
the
number one last name in the system, and it had to tear a page to make a
new
page in this area.
I found that making a table called NAMES fixed the search time I was experiencing. Two text boxes had input for whatever they keyed. I
added
the % for wildcard after any text in each box and one of the keypress events was the trigger to run it.
Select <field_list> from customer where lNameID in ( select nameID from names where Name like @Lname) and fNameID in ( select nameID from names na where na.Name like @Fname)
That has been 10-13 years ago.
On Wed, Apr 12, 2017 at 9:55 AM, Ken Dibble krdibble@stny.rr.com
wrote:
Hi folks,
I've been thinking of how I can improve the ability of my users to
find
people's names in a system that has over 30,000 people in it.
I've looked at soundex, and I've considered munging names to remove spaces, apostrophes, hyphens, etc. The thing about those approaches is
that
in order to be efficient, they require pre-processing all of the
names in
the system and storing the results, which can then be queried to find matches.
Unfortunately, that would require modifications to the database,
which I
try to avoid due to the downtime they require.
I'm looking for suggestions on how to produce results that include
close
matches on last names that doesn't require pre-processing.
I've played with various schemes to assign "weights" to matches based
on
the number of matching letters, but they all end up being very
slooooow
and
also producing too many false positives.
I suppose there are no easy answers, but if anyone has an algorithm
for
this kind of thing that they would be willing to share, I'd be
grateful.
Thanks.
Ken Dibble www.stic-cil.org
[excessive quoting removed by server]