This is an old revision of the document!
Omnidex Segments are separated into types that describe their content and their format:
| Type | File extension | Description |
|---|---|---|
| INDEX | .odxid | This segment contains index pointers representing the rows that match the criteria. |
| DATA | .dat | This segment contains data rather than index pointers. The data is in binary format without delimiters. |
| DELIMITED | .txt, .csv and .tdf | This segment contains data rather than index pointers. The data is in character format, with one value per line. |
Omnidex Segments are separated into two types of persistence that describe how filenames and file cleanup are handled:
| Persistence | Description |
|---|---|
| Temporary | Object names are unique to a connection, but may repeat across connections. Omnidex automatically manages the filenames for these segments. This segment can be dropped explicitly if needed; otherwise it will automatically dropped when the connection ends. Segments are temporary by default. |
| Permanent | Object names are unique to a connection, but may repeat across connections. The user must provide unique filenames for these segments; otherwise, the object name is used as the filename. This segment will only be deleted if explicitly dropped. |
Segments are easily creating using the CREATE SEGMENT command. The following segment types are available:
Some applications process their queries in multiple steps. The first step isolates some rows based on a first group of criteria. The second step either refines those rows, or isolates a new set of rows based on a second group of criteria. At the end of the query, all of the steps are combined to produce a final result set.
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 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.
See also: