Я бы сделал это по-разному для двух учетных записей: во-первых, я бы запустил запрос к базе данных и заполнил бы данные только правильными (отфильтрованными) данными.
Во-вторых, этот способ использования LIKE будет проходить каждый раз через все записи, делая его медленным, если у вас много пользователей. В этой ситуации я в итоге реализую «поисковую систему для бедняков», которая в основном разбирает каждый текст из этих полей на слова и вставляет в другую таблицу каждое слово с соответствующим идентификатором пользователя. Эта таблица может быть проиндексирована, и поиск будет осуществляться непосредственно с помощью «=», а не «LIKE», что значительно ускоряет поиск.
Редактировать : Отсутствие базы данных усложняет ситуацию. Тем более, что у вас много данных, и я не знаю, есть ли индексация или оптимизация при таком поиске. Если у вас есть метод кэширования данных между запросами, вы можете создать еще один источник данных с проанализированными данными. Пока пользователь ищет токены того же типа, он должен работать, но для того, чтобы найти «bob taco» как два слова одно рядом с другим, вам нужно сохранить положение слов при разборе данных и поиске. соответственно (это немного усложняет).
Например:
ID, Text
1, Hangs out at Bob Taco joint
2, Hates Bob and his taco
дал бы что-то вроде этого:
ID, Key, Pos
1, Hangs, 1
1, out, 2
1, at, 3
1, Bob, 4
1, Taco, 5
1, joint, 6
2, Hates, 1
2, Bob, 2
2, and, 3
2, his, 4
2, taco, 5
Так что теперь вам нужно искать идентификаторы, которые содержат как bob, так и taco, и разница между их значениями Pos должна быть 1. Например, ID 2 не должен быть найден, так как Pos - это 2 и 5.
Я сделал это, используя временные таблицы в SQL. Если вам нужно работать только с памятью, это может стать сложнее.