What is the difference between Search and a FTSearch? I am looking up names in our company’s names.nsf file to place in a Microsoft Access listbox and wondered which was easier/faster.
Private Sub Form_Load()
Dim ses As NotesSession
Dim db As NotesDatabase
Dim col As NotesDocumentCollection
Dim doc As NotesDocument
Dim view As NotesView
Set ses = CreateObject("Lotus.Notessession")
ses.Initialize ("detroit2")
Set db = ses.GetDatabase("MAS-NS1/MAS/DCC", "names.nsf")
Set view = db.GetView("Notes Users")
Set doc = view.GetFirstDocument
While Not (doc Is Nothing)
If doc.ColumnValues(1) <> "" Then
Me.lstLotusAddressNames.AddItem doc.ColumnValues(0)
End If
Set doc = view.GetNextDocument(doc)
Wend
I’m not sure which is faster; I’m sure you can find metrics somewhere that will tell you that. But they really are two different things; it’s not just a matter of speed and efficiency.
Search is sort of the equivalent of a SQL statement: you need a formula that says something like, “get all documents where fieldA equals this, and fieldB doesn’t equal this, and that were created after the first of last year.”
Full text search takes a single word or phrase in quotes and searches the entire document for that word. So if the search term was “applications”, any document that had the word “applications” in any field would be returned.
Right. Also important to mention is, that FTSearch only works, if a full text index actually exists (which might not always be the case).
As for performance: Search is never faster than FTSearch. It can be pretty slow in comparison, depending on what you do. The more documents a Search will return, the closer it gets to FTSearch, at least. See this article here on developerWorks:
And it’s important to also point out that while you will get dramatically increased search performance if you create a FT index, you are consuming more disk space (a frequently-used estimate is 30% more) and you are incurring more disk i/o for index updates. And since overall Domino performance is usually more dependent on disk i/o than anything else, using FT indexes can cut your overall performance But if searches are more frequent than updates, the savings might well outweigh the costs; and of course, one FT index for one database – even a big one – is unlikely to make or break a server.
Less efficiently NOT only means “slower”. It ALSO means, that you will get different results than with a full text index already created, depending on your search term. In particular, wildcards will not work if there’s no full-text index. And - I don’t have to tell you both, but just for the records - web search requires the index to be build.
And one more thought on performance. Even if Domino performance is often disc i/o limited, this does not necessarily mean, not creating FT indexes will save you much. If the code still contains FTSearches, the building of temporarily indexes will at least partly eat up what might have been gained.
The point being, it’s hard to predict the impact. Human factors come into it, too. I.e., if searches are fast, people will do more of them.
Anyhow, I am a huge fan of FT search and FT indexes. I couldn’t live without FT search in my mail file and numerous other databases that I’m in every day. To me, it is always worth the cost in disk and the cost in i/o headroom for building indexes. But I know admins in the enterprise world who take a very different position.
FTSearch is using the full text search index, Search is basically building a dynamic view to searh.It is possible for a Full Text to be out of date, whereas the db.search is created on request so is always up to date.
