Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
admin:indexing:indexes:types [2011/01/18 17:19]
els created
admin:indexing:indexes:types [2016/06/28 22:38] (current)
Line 1: Line 1:
 +~~NOTOC~~
 +
 {{page>:​top_add&​nofooter&​noeditbtn}} {{page>:​top_add&​nofooter&​noeditbtn}}
  
Line 6: Line 8:
  
 [[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. ​ 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 ===
 +
 +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.  ​
 +
 +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 a 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 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 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 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 another word, or adjacent as a phrase. ​ FullText Indexes necessarily have more overhead than QuickText Indexes.
 +
 +=== Custom Indexes ===
 +
 +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.
  
 ====  ====  ====  ==== 
 
Back to top
admin/indexing/indexes/types.1295371190.txt.gz · Last modified: 2016/06/28 22:38 (external edit)