Raczej szybkim rozwiązaniem specyficznym dla domeny może być obliczenie podobieństwa ciągów za pomocą SOUNDEX i odległości liczbowej między 2 ciągami. Pomoże to tylko wtedy, gdy masz dużo kodów produktów.
Używając prostego UDF, jak poniżej, możesz wyodrębnić znaki numeryczne z ciągu, dzięki czemu możesz uzyskać 2200 z „CLC 2200npk” i 1100 z „CLC 1100”, dzięki czemu możesz teraz określić bliskość na podstawie wyjścia SOUNDEX każdego wejścia jak również bliskość składnika numerycznego każdego wejścia.
CREATE Function [dbo].[ExtractNumeric](@input VARCHAR(1000))
RETURNS INT
AS
BEGIN
WHILE PATINDEX('%[^0-9]%', @input) > 0
BEGIN
SET @input = STUFF(@input, PATINDEX('%[^0-9]%', @input), 1, '')
END
IF @input = '' OR @input IS NULL
SET @input = '0'
RETURN CAST(@input AS INT)
END
GO
Jeśli chodzi o algorytmy ogólnego przeznaczenia, istnieje kilka, które mogą pomóc z różnym stopniem sukcesu w zależności od rozmiaru zestawu danych i wymagań dotyczących wydajności. (oba linki mają dostępne implementacje TSQL)
- Podwójny metafon — ten algorytm zapewnia lepsze dopasowanie niż soundex kosztem szybkości, ale jest naprawdę dobry do poprawiania pisowni.
- Odległość Levenshteina — oblicza, ile naciśnięć klawiszy potrzeba, aby zamienić jeden ciąg w inny, na przykład, aby przejść z „CLC 2200npk” do „CLC 2200” wynosi 3, podczas gdy z „CLC 2200npk” do „CLC 1100” wynosi 5.
Oto interesujący artykuł, który stosuje oba algorytmy razem, co może dać ci kilka pomysłów.
Mam nadzieję, że niektóre z nich trochę pomogą.
EDYCJA:Oto znacznie szybsza częściowa implementacja Levenshtein Distance (przeczytaj post, który nie zwróci dokładnie takich samych wyników jak normalny). Na moim stole testowym zawierającym 125000 wierszy działa on w 6 sekund w porównaniu do 60 sekund dla pierwszego, z którym się połączyłem.
