Postby BeeJay » Fri Oct 30, 2009 2:34 pm
Searching support is often a whole module in its own right, with a number of systems implementing their own keywording algorithms and "keywording objects" to prebuild all the "keywords" for a given object into some form of keyword/search manager. Without going to this extent of development, you do have some rather crude options available that while they will "work" are not options that would scale well for large data volumes.
1. The simplest approach would be to take a "filter string" and simply do a String::pos call on the appropriate string properties to see if they're a match.
2. Another approach, assuming you're supporting searching only over a single field such as surname could be to have a dictionary of people keyed by surname, then use an iterator and startKeyGeq to quickly get to the first "match", and then continue iterating until the name is no longer a match. This won't work if you need to support finding a match part way through a surname but will be faster for a search for say john* to find all the johns, johnsons, johnstons, and johnstones in your system.
As I said at the beginning, neither of these options is particularly elegant, and I'm certainly not recommending them as good options in a real world commercial application as they have obvious limitations, but they may work for your requirements.
If you're happy to invest the time, and it's not going to be an over-engineering of your project requirements, then to support better searching you'll need to look at creating a search manager with a collection of keywords, with each keyword having a collection of the objects that "contain" that keyword. Then you can write some much better performing search code to get all the keywords that match a given search criteria, then combine all the objects for each of those keywords into your final result set. You do, however, have to have some way of "keywording" the objects as you create/update them. For reasons of contention and performance, a lot of systems will engineer a lazy update pattern to do this keywording via a background process. This means that the actual updating of those objects doesn't also have to do the keywording, which could have a dramatic negative impact on the overall transaction time, and means you only have a single updater process affecting the keyword manager and keyword objects.
Cheers,
BeeJay.