This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
admin:indexing:indexes:types [2011/01/18 17:38] els |
admin:indexing:indexes:types [2011/01/24 15:27] 127.0.0.1 external edit |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ~~NOTOC~~ | ||
| {{page>:top_add&nofooter&noeditbtn}} | {{page>:top_add&nofooter&noeditbtn}} | ||
| Line 6: | Line 7: | ||
| [[admin:indexing:indexes:home|Overview]] | | [[admin:indexing:indexes:home|Overview]] | | ||
| - | **[[admin:indexing:indexes:types|Types]]** | | + | **[[admin:indexing:indexes:types|Index Types]]** | |
| - | [[admin:indexing:indexes:options|Options]] | | + | [[admin:indexing:indexes:options|Index Options]] | |
| - | [[admin:indexing:indexes:groups|Index Groups]] | | + | [[admin:indexing:indexes:groups|Index Groups]] |
| - | [[admin:indexing:indexes:multicol|Multi-column Indexes]] | | + | |
| - | [[admin:indexing:indexes:prejoin|Pre-joined Indexes]] | + | |
| ==== Index Types ==== | ==== Index Types ==== | ||
| - | Omnidex supports four types of indexes. The first two types are the most common, but all are valuable: | + | Omnidex supports four types of indexes. These types of indexes provide support for handling Omnidex criteria, table joins, aggregations and ordering. They also support both textual data and non-textual data. Most databases use a combination of these index types to meet their indexing needs. |
| - | + | ||
| - | * **Omnidex Indexes** are used to optimize criteria, table joins, aggregations and ordering. | + | |
| - | * **QuickText Indexes** are used to index small text fields, such as names, addresses, product descriptions and general text. | + | |
| - | * **FullText Indexes** are used to index large blocks of text. | + | |
| - | * **Custom Indexes** allow specialized options which are appropriate for specific situations. | + | |
| === Omnidex Indexes === | === Omnidex Indexes === | ||
| - | Omnidex indexes provide the bulk of Omnidex functionality. These indexes are placed on | + | Omnidex Indexes provide the bulk of Omnidex functionality. These indexes are placed on |
| columns that are involved in Omnidex criteria, table joins, aggregations and ordering. Omnidex indexes can also be used to retrieve data without having to access the database. | columns that are involved in Omnidex criteria, table joins, aggregations and ordering. Omnidex indexes can also be used to retrieve data without having to access the database. | ||
| - | Typically, administrators place Omnidex indexes on all columns that are involved in the SQL statement. The Omnidex SQL Engine will use each index in different ways depending on how the corresponding column is used in the SQL statement. In a given query, some indexes will satisfy criteria or support table joins, while other indexes will fulfill aggregations or ordering. In a subsequent query, those same indexes may get used for different purpose. | + | Typically, administrators place Omnidex Indexes on all columns that are involved in the SQL statement. The Omnidex SQL Engine will use each index in different ways depending on how the corresponding column is used in the SQL statement. In a given query, some indexes will satisfy criteria or support table joins, while other indexes will fulfill aggregations or ordering. In a subsequent query, those same indexes may get used for different purpose. |
| + | |||
| + | An Omnidex Index can also be created with multiple columns. These indexes are valuable for optimizing SQL statements with multiple columns in the GROUP BY clause, ORDER BY clauses or the aggregation functions (COUNT, SUM, MIN, MAX and AVERAGE). | ||
| + | |||
| + | == Omnidex Bitmap Index - A common variation == | ||
| - | An Omnidex index can also be created with multiple columns. These indexes are valuable for optimizing SQL statements with multiple columns in the GROUP BY clause, ORDER BY clauses or the aggregation functions (COUNT, SUM, MIN, MAX and AVERAGE). | + | An Omnidex Bitmap Index uses a bitmap storage format to reduce disk space usage and speed performance. Omnidex Bitmap Indexes are appropriate for non-textual columns with thirty or less distinct values. |
| === QuickText Indexes === | === QuickText Indexes === | ||
| - | QuickText indexes are specialty indexes designed for small blocks of text, such as names, addresses, descriptions and general text. QuickText indexes parse the contents of the column so that each word is indexed separately. Queries can then mention just a few of the words in that column rather than having to mention the whole field. For example, a field containing the name "John Q. Doe" can be located by just asking for "John" or "John Doe". QuickText indexes provide basic text searches at the same speed as Omnidex indexes. | + | QuickText Indexes are designed for small blocks of text, such as names, addresses, descriptions and general text. QuickText Indexes parse the contents of the column so that each word is indexed separately. Queries can then mention just a few of the words in that column rather than having to mention the whole column. For example, a column containing the name "John Q. Doe" can be located by just asking for "John" or "John Doe". QuickText Indexes provide basic text searches at the same speed as Omnidex Indexes. |
| === FullText Indexes === | === FullText Indexes === | ||
| - | FullText indexes are specialty indexes designed for large blocks of text, such as abstracts, articles and text documents. FullText indexes parse the contents of the column so that each word is indexed separately. FullText indexes also track the position of each word in the field to aid in providing relevancy scores. Queries can also use special syntax to require that one word be a certain distance from other word. FullText indexes necessarily have more overhead than QuickText indexes. | + | FullText Indexes are designed for large blocks of text, such as abstracts, articles and text documents. FullText Indexes parse the contents of the column so that each word is indexed separately. FullText Indexes also track the position of each word in the field to aid in providing relevancy scores. Queries can use special syntax to require that one word be a certain distance from other word, or adjacent as a phrase. FullText Indexes necessarily have more overhead than QuickText Indexes. |
| === Custom Indexes === | === Custom Indexes === | ||
| - | Omnidex also supports Custom Indexes which allow more granular control over the options used on an index. Custom indexes can also be used to index a portion of a column or a concatenation of multiple columns. | + | Custom Indexes allow more granular control over the options used on an index. A Custom Index is also used in special situations such as pre-joined indexes or partial-column indexes. |
| ==== ==== | ==== ==== | ||