Understanding Search Methodologies

目录

原文链接：http://www-01.ibm.com/support/docview.wss?rs=3214&context=SSLKT6&dc=DB560&dc=DB520&uid=swg21321289&loc=en_US&cs=UTF-8&lang=en&rss=ct3214tivoli

Technote (FAQ)

Question

Is there some process that Maximo uses to search for records in the database and is there a best practice for the configuration of it?

Cause

Limited documentation

Answer

Maximo supports four different search methodologies including Exact, None, Text, and Wildcard. Each field in the Maximo database can be set to employ any of these methods with the limitation of “Text” searching, as it does not apply to numeric columns.

To reduce user confusion, it is a best practice use search types consistently. If some fields are set to “Exact” and others to “Wildcard”, it will be difficult for users to remember which search type is valid in which field. The best approach is to set all fields longer than twenty-five (25) characters to “Text” style searching and all other character fields to “Exact”. Using these criteria, training users on the use of wildcards, and training users on how to identify “Text” search fields will be very powerful in attaining best performance from database searches while providing simplicity in searching.

Any search executed by Maximo generates an SQL select statement that is passed to the database server to find records. The database uses relational database technology indexing to search for records. Indexes can be thought of as a sorted binary representation of the columns defined by the index. Finding records using an index is very fast and efficient, requires minimal memory, and requires minimal storage I/O. If an index is not defined for a particular search or an index cannot be used, each individual record in a table must me read into memory and searched for the values. Non-indexed searching is very inefficient and is known as a “Full Table Scan”.

“Exact” default searching: When a fields search behavior defaults to the “Exact” search method, searches are performed on fields with the exact value the user enters. This method is case sensitive and will not find items where the case of the value entered is different.

If a user enters the value “Boiler” in an “Exact” field search, only records where the entire column matches the word “Boiler” will be found. Instances of “BOILER”, “Boilers”, “Boiler is overheating” will not be found.

“Exact” searching is the most efficient database search method as long as the field searched is indexed. This method enables the database to analyze the SQL select statement and employ indexes to their maximum potential.

Example:

SELECT * from workorder where wonum = ‘123’;

Additional functionality can be included in an “Exact” search by including wildcards in the search criteria; however, caution should be exercised when using wildcards as they can impact performance of not only the search executed but also all users using the same database.

Wildcard characters include “%” (percent sign) and the “_” (underscore character). The most common wildcard is the “%”.

If a user is searching for a record that starts with “Boiler” a value of “Boiler%” may be entered and all records where the specified column starts with “Boiler” will be found including “Boiler”, “Boilers”, “Boiler is overheating”. This method can still use indexes and will be fairly efficient though not as efficient as an “Exact” search.

If a user is searching for a record that contains “Boiler” somewhere in the field, a value of “%Boiler%” may be entered and all records where the specified column contains the word “Boiler” will be found including “Boiler”, “Boilers”, “Boiler is overheating”, “The Boiler” and “When the Boilers are on”. This method is the most inefficient search. Indexes cannot be used with this search approach and each record from the table must be read and searched for the value. Users should avoid this search method whenever possible. This search method is the same as employing the “Wildcard” search method as the default search methodology for a field.

Underscore characters (“_“) are rarely used as wildcards. These can be used to search for variants on a single character. A user can enter “the animal is _ame” and the results can return, “the animal is lame” and “the animal is tame”. The same caveat applies to using this character as the first character in a search as the “%”. This approach will disable the use of indexes and is very inefficient.

“None” default method: This method is designed to disable searching on the field it is assigned to. This method is often used when extra columns are defined to maintain data but business requirements do not need users to be able to search on those fields.

“Text” default searching: When a fields search behavior defaults to the “Text” search method, searches are performed on fields using a complex text algorithm to determine the root of the word searched. Searches are done for all instances that contain the root word or any derivative of the root word. This method is not case sensitive and will find items regardless of the case entered.

If a user enters the value “Boiler” in a “Text” field search, records where the column matches the word “Boiler” will be found. In addition, instances of “BOILER”, “Boilers”, “Boiler is overheating”, “Boiling” and “Boiled” will also be found.

While “Text” searching holds some characteristics in common with “Wildcard” searching, it is much more efficient because preprocessing is done by the database server to determine the best use of indexes. This method enables the database to analyze the SQL select statement and employ indexes to find records.

“Text” searches have a substantial number of rules associated with them. Users may often be confused by the results of a text search. Database technology “Text” searching does not employ punctuation in the traditional form. Database technologies have a method designed to remove punctuation from “Text” searches.

In an effort to expand on the “Text” search capability, Maximo employs a system to replace certain punctuation characters.

Commas “,” are the same as the logical “OR”. This allows a user to search for value1 OR value2 with a single search but also means you cannot search a text index for the word “OR”

Wildcards and hyphens are not modified and are passed as is to the database to provide wildcard like functionality. The hyphen (minus sign or dash) is passed through to the database where it is interpreted as the MINUS operation. This function provides a sort of “except” functionality where words with a hyphen between them means to search for instances of the word before the hyphen except where the word following the hyphen exists.

Cases of reserved words in searches are ignored so searches will return the same results as those same searches without the reserved word included.

The database parses out any remaining punctuation from the search string and searches using the database “Text” search rules.

Some items may be reserved words and prevent typical searching if used incorrectly

Examples:

Because of the hyphen functionality, searching for “BOILER-99” the pass through of the hyphen will cause the CONTAINS function to be constructed as “contains(columnname, ’ $BOILER -$99’)” and will return all records which contain forms of the word “BOILER” and do not contain the number “99”. This means it will return:

98 large boilers
1 boiler
BOILERS with pumps

but will not return

99 boilers
boilers in building 99
99 pipes in a boiler

Searching for “Boiler-1” in a “Text” search field will search for the word “Boiler” but in fact, this search will not return what might be expected because the number 1 is a reserved word and therefore is not indexed. According to the database rules, reserved words are ignored and essentially stripped out of the search so the search for “Boiler-1” will return the same result set as the search for “Boiler”

Searching for “lightblub, 100W” will search for all records that have either “lightbulb” OR “100W” in them.

“Text” searching rules can cause problems if naming conventions include dashes, percent signs, underscores or commas. During implementation, it is a best practice to stay away from naming conventions that use these characters.

Out of the box Maximo employs “Text” searches for character fields exceeding twenty-five (25) characters in length. Although these searches are not as efficient as ‘Exact” searches, they are many times better than “Wildcard” searches. Users should be trained on “Text” search usage. It is recommended that “Text” remain the search type for long character fields.

“Wildcard” default searching: When a fields search behavior defaults to the “Wildcard” search method, searches are performed on fields with the “%” wildcard on the beginning and end of the search value the user enters. This method is case sensitive and will not find items where the case of the value entered is different.

If a user enters the value “Boiler” in a “Wildcard” field search, all records where the entire column matches the word “Boiler” will be found. Instances of “BOILER” will not be found because it is not the same case.

“Wildcard” searching is the least efficient database search method because it cannot use indexes. This method appears to provide the most flexibility in searching but, as a default, becomes too demanding for the database server when large numbers of concurrent users are using it.

Example:

SELECT * from workorder where wonum = ‘%123%’;

When “Wildcard” searches are enabled by default, users can force the use of any available indexes by preceding the search value with an “=” (equal sign). This will change the search method to an “Exact” search method with a trailing “%”. When the default search method is “Wildcard” users should be encouraged to use “=” in front of All search values unless absolutely necessary.

Wildcard searches include “%” (percent sign) at the beginning and end of each search value.

If a user is searching for a record that contains “Boiler” a value of “Boiler” may be entered and all records where the specified column contains the word “Boiler” will be found including “Boiler”, “Boilers”, “Boiler is overheating”, “The Boiler” and “When the Boilers are on”. This method is the most inefficient search. Indexes cannot be used with this search approach and each record from the table must be read and searched for the value. Users should avoid this search method whenever possible.

If a user is searching for a record that starts with “Boiler”, a value of “=Boiler” may be entered and all records where the specified column starts with the word “Boiler” will be found including “Boiler”, “Boilers”. This search method is the same as employing the “Exact” search method and appending a “%” to the search value.

Out of the box Maximo uses the ‘Wildcard” search for all character fields shorter than twenty-six (26) characters. It is a best practice to consider changing the default search method to “Exact” when concurrent usage is greater than 50 users.

For more information on database Text indexes review the Oracle Text Reference Guide.

Date searches are not a specific type of Maximo search methodology and are not covered by this document, however; there are Oracle and SQL Server related documents available for specific SQL syntax related to date searching. Date queries can become quite complex and it is recommended that collaboration with a DBA be included in the planning of date searches.

Oracle - http://www.ibm.com/support/docview.wss?uid=swg21262277

SQL Server - http://www.ibm.com/support/docview.wss?uid=swg21295192

Related information

Maximo Support Common Topics
http://www.ibm.com/support/docview.wss?uid=swg21418666

Cross reference information

Segment	Product	Component	Platform	Version	Edition
Systems and Asset Management	Tivoli Asset Management for IT	All
Systems and Asset Management	IBM Maximo Asset Management Essentials	All
Systems and Asset Management	Tivoli Change and Configuration Management Database
Systems and Asset Management	Tivoli Service Request Manager
Systems and Asset Management	Tivoli Asset Management for IT