This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
admin:indexing:creation:home [2012/01/25 22:45] doc |
admin:indexing:creation:home [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 4: | Line 4: | ||
| ====== Administration: Omnidex Indexing ====== | ====== Administration: Omnidex Indexing ====== | ||
| - | ===== Indexing Creation ===== | + | ===== Index Creation ===== |
| **[[admin:indexing:creation:home|Overview]]** | | **[[admin:indexing:creation:home|Overview]]** | | ||
| [[admin:indexing:creation:declaring|Declaring Indexes]] | | [[admin:indexing:creation:declaring|Declaring Indexes]] | | ||
| [[admin:indexing:creation:updating|Updating Indexes]] | | [[admin:indexing:creation:updating|Updating Indexes]] | | ||
| - | [[admin:indexing:creation:standalone|Standalone Indexes]] | | ||
| [[admin:indexing:creation:files|Index Files]] | | [[admin:indexing:creation:files|Index Files]] | | ||
| - | [[admin:indexing:creation:updating|Maintenance]] | + | [[admin:indexing:creation:performance|Performance]] |
| + | ---- | ||
| ==== Overview ==== | ==== Overview ==== | ||
| - | With most relational databases, such as Oracle, SQL Server and MySQL, the administrator creates a few carefully-chosen indexes on a table. These indexes are created using the CREATE INDEX statement, which sequentially scans the table and populates the index. A table with three or four indexes will require three or four CREATE INDEX statements, each of which will sequentially scan the table and populate the index. | + | Most relational databases, such as Oracle, SQL Server and MySQL, encourage administrators to create a few carefully-chosen indexes on a table. These indexes are created using the CREATE INDEX statement, which sequentially scans the table and populates the index. A table with three or four indexes will require three or four CREATE INDEX statements, each of which will sequentially scan the table and populate the index. |
| - | Omnidex's indexing strategy often results in hundreds of indexes per table, so Omnidex takes a more optimized approach to index creation. It is inefficient to sequentially scan the table for each and every index, regardless of whether there will be three or four indexes, or hundreds of indexes. With Omnidex, you first declare all of the properties and options for all of the indexes, and then they are all populated with one command. This command scans the table once, populating all of the indexes at the same time. This allows indexes to be created at a much faster rate than the relational databases. | + | Omnidex's indexing strategy often results in hundreds of indexes per table; therefore, Omnidex takes a more optimized approach to index creation. It is inefficient to sequentially scan the table for each and every index, regardless of whether there will be a few indexes, or hundreds of indexes. With Omnidex, you first declare all of the properties and options for all of the indexes, and then populate all of the indexes with one command. This command scans the table just once, populating all of the indexes at the same time. This allows indexes to be created at a much faster rate than the relational databases. |
| If needed, Omnidex does allow an index to be created individually; however, this is not commonly needed. Omnidex generally populates indexes at a rate of 1-5 billion keywords per hour, depending on the underlying hardware. This fast indexing rate makes it convenient to simply rebuild all of the indexes, usually in minutes. | If needed, Omnidex does allow an index to be created individually; however, this is not commonly needed. Omnidex generally populates indexes at a rate of 1-5 billion keywords per hour, depending on the underlying hardware. This fast indexing rate makes it convenient to simply rebuild all of the indexes, usually in minutes. | ||