As of now, the auto detection seems to work like this:
If 1 search word is entered the mode is "%like%" and if more words are entered, Cobalt uses fulltext boolean mode.
For me this does not really provide the best possible approach.
I would suggest following scheme:
Case 1:
1 search word is entered --> example "Hotel"
The search starts with a fulltext search in boolean mode.
If no result is returned, it will search again in fulltext boolean mode now with an asterisk as wildcard operator --> "Hotel*"
If no result again, then it will shift to a "%LIKE%" search as last resort.
The search indicator ("search worning" -> Cobalt term) can have a small optional tooltip indicator, showing what search type was used to get the result.
Real world example:
I have a section with 38K records.
In Full text mode, the Query, counting the number of results, takes
0.3 ms (0 result)
1.05ms (30 results)
7.19ms (637 results)
If we follow this process the overhead against the "%LIKE%" search would be very minimal .. the average maybe around 1-3ms.
It only needs to do the count query (See also another search query optimization here )
Case 2:
2 or more search words are entered like "Hotel Garden"
As it is now, the search will return ALL records with "Hotel" AND ALL records with "Garden".
Based on normal search behaviour, (i presume) the user would expect ALL records with "Hotel" AND "Garden" in it. --> "+Hotel +Garden"
Therefore the automatic detection search should start with a boolean fulltext query like this "+Hotel +Garden".
The search text indicator box can then contain "Hotel AND Garden"
Maybe the "Auto detection" can then be renamed to "Intelligent search".
Another enhancement could be an additional (optional) icon to let the user even choose the search mode.
More to follow ...
As of now, the auto detection seems to work like this:
If 1 search word is entered the mode is "%like%" and if more words are entered, Cobalt uses fulltext boolean mode.
For me this does not really provide the best possible approach.
I would suggest following scheme:
Case 1:
1 search word is entered --> example "Hotel"
The search starts with a fulltext search in boolean mode.
If no result is returned, it will search again in fulltext boolean mode now with an asterisk as wildcard operator --> "Hotel*"
If no result again, then it will shift to a "%LIKE%" search as last resort.
The search indicator ("search worning" -> Cobalt term) can have a small optional tooltip indicator, showing what search type was used to get the result.
Real world example:
I have a section with 38K records.
In Full text mode, the Query, counting the number of results, takes
0.3 ms (0 result)
1.05ms (30 results)
7.19ms (637 results)
If we follow this process the overhead against the "%LIKE%" search would be very minimal .. the average maybe around 1-3ms.
It only needs to do the count query (See also another search query optimization here )
Case 2:
2 or more search words are entered like "Hotel Garden"
As it is now, the search will return ALL records with "Hotel" AND ALL records with "Garden".
Based on normal search behaviour, (i presume) the user would expect ALL records with "Hotel" AND "Garden" in it. --> "+Hotel +Garden"
Therefore the automatic detection search should start with a boolean fulltext query like this "+Hotel +Garden".
The search text indicator box can then contain "Hotel AND Garden"
Maybe the "Auto detection" can then be renamed to "Intelligent search".
Another enhancement could be an additional (optional) icon to let the user even choose the search mode.
More to follow ...