Dit is heel raar, ik heb zelf de afgelopen 15 jaar vaak met dit probleem geworsteld en kom over het algemeen met structuren die netnummers, landcodes en nummers scheiden in afzonderlijke velden, enz. Maar terwijl ik je vraag las, kwam er net een andere oplossing tevoorschijn in mijn hoofd, het vereist wel een apart veld, dus misschien niet geschikt voor jou.
Je zou een apart veld kunnen hebben met de naam reverse_phone_number, dit automatisch laten invullen door de DB-engine en wanneer mensen zoeken, draai je gewoon de zoekstring om en gebruik je het geïndexeerde reverse-veld met slechts een % aan het einde van de like-string, waardoor het gebruik van de index.
Afhankelijk van uw DB-engine kunt u mogelijk een index maken op basis van een door de gebruiker gedefinieerde functie die het omgekeerde voor u doet, zodat u geen extra veld nodig heeft.
In sommige landen, b.v. het VK, hebt u mogelijk een probleem met voorloopnullen. Een Brits telefoonnummer wordt weergegeven als (netnummer)(Telefoonnummer), b.v. 01634 511098, wanneer dit wordt geïnternationaliseerd, wordt de voorloopnul van het netnummer verwijderd en worden de internationale kiescode (+ of 00) en de landcode (44) toegevoegd. Dit resulteert in een internationaal telefoonnummer van +441634511098. Elke gebruiker die zoekt naar 0163451109 zou het telefoonnummer niet vinden als het in internationaal formaat is ingevoerd. U kunt dit probleem oplossen door voorloopnullen uit de zoekreeks te verwijderen.
BEWERKEN Op basis van suggesties van Ollie Jones moet u het nummer opslaan zoals ingevoerd door de gebruiker en vervolgens voorloopnullen, leestekens en witruimte van het nummer verwijderen voordat u het omdraait en opslaat in het omgekeerde veld. Gebruik vervolgens hetzelfde algoritme om de zoekreeks te verwijderen voordat u achteruitgaat, zoek het record en geef het oorspronkelijk ingevoerde nummer weer aan de gebruiker.