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 22:44] 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:index|Index Segments]] | | ||
| [[admin:features:segments:creating|Creating Segments]] | | [[admin:features:segments:creating|Creating Segments]] | | ||
| - | [[admin:features:segments:attaching|Attaching Segments]] |[[admin:features:segments:queries|Querying Segments]] | | + | [[admin:features:segments:querying|Querying Segments]] | |
| - | [[admin:features:segments:dropping|Dropping Segments]] | | + | [[admin:features:segments:dropping|Dropping Segments]] |
| - | [[admin:features:segments:archiving|Archiving Segements]] | + | |
| ---- | ---- | ||
| 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 can be either temporary or permanent. Temporary segments are managed by Omnidex, and can be either dropped explicitly or can be automatically dropped when the connection ends. Permanent segments are managed by the application and will persist once the connection ends. | + | |
| - | + | ||
| - | Omnidex Segments are a powerful tool for managing more complex queries, and are also key to maintaining fast performance in multi-step queries. | + | |