# Best practice for legacy address database searches

**URL:** <https://discuss.elastic.co/t/best-practice-for-legacy-address-database-searches/366804>\
**Category:** Elasticsearch\
**Created:** [September 19, 2024, 2:49pm UTC](https://discuss.elastic.co/t/best-practice-for-legacy-address-database-searches/366804 "2024-09-19T14:49:17Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Stubbs](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stubbs/32/137731_2.png) [@Stubbs](https://discuss.elastic.co/u/Stubbs)\
**Post date:** [September 19, 2024, 2:49pm UTC](https://discuss.elastic.co/t/best-practice-for-legacy-address-database-searches/366804/1 "2024-09-19T14:49:17Z")

</div>

We have a legacy database of addresses that contains data from multiple countries and is quite frankly, a mess! We have lots of duplicates, lots of entries where the same postcode is entered with and without spaces and other variations of formatting and I'm looking for any help with best practice on indexing the data in a way that makes searching it easier and more useful.

I think one of the reasons we have duplicates around the postcode is when someone searches for A112AB it's not matching A1 12AB, but I'm pretty sure we're not the first people to have this issue so I was wondering if anyone has a set of best practices for handling legacy data sets like this?

---

<div class="post-metadata">

**Author:** ![iulia](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/iulia/32/124658_2.png) [@iulia](https://discuss.elastic.co/u/iulia)\
**Post date:** [September 19, 2024, 6:01pm UTC](https://discuss.elastic.co/t/best-practice-for-legacy-address-database-searches/366804/2 "2024-09-19T18:01:03Z")

</div>

Hi!

There are indeed a few things you could look at.

Firstly, for common misspellings, there's always [fuzzy search](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-fuzzy-query.html) that can let you find results even where the words are a few changes away from the actual term. (see [this opster blog](https://opster.com/guides/elasticsearch/search-apis/elasticsearch-fuzzy-query/) for more info on customizing these as a starting point)

On the other hand, for your example with the IDs - since neither are actual words, the fuzzy search might not do much.

I'd recommend taking a look at the various options for cleaning data within the [text analyzers](https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-overview.html). Especially either stemming and tokenizing your semantic data to match more similar phrases to the same concepts; or defining your [own synonims](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-with-synonyms.html#:~:text=Synonyms%20are%20words%20or%20phrases,the%20scope%20of%20search%20results.).  
The example there was `ipod, i-pod, i pod => ipod, i-pod, i pod` which you could set up for some of those postal codes or more common and well-known mistakes you've noticed.

For the mistakes you may not have found yet (the ones you'd actually need most help with) - this may be more of a data analysis or even ML issue. Like looking at the value distribution across each data category and finding outliers; clustering similar values; or even some classification? You might find the [more like this query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-mlt-query.html) useful to find more of the "false duplicates" you mentioned.

Hope this helps as a starting point!