This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
admin:features:segments:home [2012/03/01 20:54] doc |
admin:features:segments:home [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 8: | Line 8: | ||
| **[[admin:features:segments:home|Overview]]** | | **[[admin:features:segments:home|Overview]]** | | ||
| - | [[admin:features:segments:types|Segment Types]] | | + | [[admin:features:segments:index|Index Segments]] | |
| [[admin:features:segments:creating|Creating Segments]] | | [[admin:features:segments:creating|Creating Segments]] | | ||
| - | [[admin:features:segments:queries|Querying Segments]] | | + | [[admin:features:segments:querying|Querying Segments]] | |
| - | [[admin:features:segments:archiving|Archiving Segements]] | + | [[admin:features:segments:dropping|Dropping Segments]] |
| ---- | ---- | ||
| Line 20: | Line 20: | ||
| With relational databases, these multi-step queries are often done by managing a series of temporary tables, usually containing only one column such as a primary key. Each step of the query refines these temporary tables, ultimately producing a final table with the final result set. This approach is significantly slower due to the writing and rewriting of the temporary tables; however, the need for this approach can be a fundamental requirement of the application. | With relational databases, these multi-step queries are often done by managing a series of temporary tables, usually containing only one column such as a primary key. Each step of the query refines these temporary tables, ultimately producing a final table with the final result set. This approach is significantly slower due to the writing and rewriting of the temporary tables; however, the need for this approach can be a fundamental requirement of the application. | ||
| - | Omnidex Segments provide a higher-speed approach to multi-step queries. Instead of writing and rewriting temporary tables, Omnidex Segments record the index pointers for each step and allow those segments to be reused in future queries. These index segments are much more efficient than temporary tables, and can be directly applied against Omnidex indexes in future queries. This greatly improves the performance of multi-step queries. | + | Omnidex Segments provide a higher-speed approach to multi-step queries. Instead of writing and rewriting temporary tables, Omnidex Segments will record the index pointers for each step into temporary objects and allow those segments to be reused in future queries. These index segments are much more efficient than temporary tables, and can be directly applied against Omnidex indexes in future queries. This greatly improves the performance of multi-step queries. |
| - | + | ||
| - | Omnidex Segments can also be used to incorporate criteria from external sources. For example, a user may provide a file containing specific Customer Numbers, or a file of certain Zip Codes, to be applied as criteria in a search. This data does not need to be imported into a temporary table. Instead, these files can be considered user-supplied, data segments and can be easily applied at any search step. | + | |
| - | + | ||
| - | Omnidex Segments are a powerful tool for managing more complex queries, and are also key to maintaining fast performance in multi-step queries. | + | |
| ==== ==== | ==== ==== | ||
| - | **[[admin:features:segments:types|Next]]** | + | **[[admin:features:segments:creating|Next]]** |