>>>I found a switch at the table level, where there seems to be additional properties not available under the Storage tree. There is a switch to use or not the stoplist. When disabled, the index becomes bloated. So, we cannot use that. I will see about allowing specific words, which means, moving them out of the stoplist table. But, for now, I would suggest, when going for an exact match, to avoid the "the" in front and use the rest such as "report writer".
>>>
>>>Because, basically, using "the report writer" and "report writer", as search criteria, returns the same amount of records because the word "the" is omitted from the search.
>>
>>In other words, use both criteria - the index and LIKE (as I also suggested originally).
>>
>>The index will be quick and then if you're looking for exact phrase, you filter the results with LIKE.
>
>I once did that on dbfs, indexing for most of the words (omitted a few - articles, short lowercase words etc), on a fpt of about 190 megs, and the size of the index table was 59M dbf + 64M cdx, and it would give the result set blazingly fast. Then searching for exact phrase in the result set, using simple atc() on the phrase was easy and just as fast.
There must be a tremendous percentage of words that occurs multi fold. A reduction from 190 to 59 is less than I'd expect. How come?
Groet,
Peter de Valença
Constructive frustration is the breeding ground of genius.
If there’s no willingness to moderate for the sake of good debate, then I have no willingness to debate at all.
Let's develop superb standards that will end the holy wars.
"There are three types of people: Alphas and Betas", said the beta decisively.
If you find this message rude or offensive or stupid, please take a step away from the keyboard and try to think calmly about an eventual a possible alternative explanation of my message.