Start simple
For a few thousand records, matching against a handful of indexed fields is adequate and requires no additional infrastructure. Do not reach for a search engine before you need one.
Adding a dedicated search service to an application with four thousand records is adding an operational dependency for a problem you do not have.
What people actually search for
- Reference numbers — exact matching, must work
- Names, frequently misspelled or partial
- Phone numbers and postcodes in inconsistent formats
- Words from a description or note
- Combinations of the above
Reference numbers are the most common and the most likely to be handled badly by a general search that tokenises them.
Normalise before matching
- Strip spaces and punctuation from reference numbers and phone numbers
- Match case-insensitively
- Handle partial matches on names
- Search several fields, weighted by relevance
- Return the most likely first, not the most recent
Scale in stages
| Volume | Approach |
|---|---|
| Under a few thousand | Indexed field matching |
| Tens of thousands | Database full-text search |
| Hundreds of thousands | Dedicated search index |
| Meaning matters more than words | Semantic search |
Respect permissions in search
Search results must be filtered by what the user may see, before ranking rather than after. A search that reveals the existence of records the user cannot open is still a leak.
That includes any autocomplete or type-ahead, which is frequently implemented separately and forgotten.