This is an old revision of the document!
Omnidex applications tend to have a lifecycle. While they share some similarities with normal applications, they also have some unique steps that focus on the Omnidex indexes. The typical Omnidex application has six stages in its lifecycle:
As with most applications, this is the most important step of the entire application lifecycle. During the design step, key decisions are made about how to approach Omnidex queries and updates in the application. These decisions can lead to high-performing applications, and they can also lead to poor performance. It is worth spending the needed time on this step.
Design begins with obtaining three key pieces of information:
The database schema should show all of the tables, their respective columns and datatypes, and their respective primary and foreign constraints. This schema provides an understanding of the table relationships that is necessary for optimizing table joins. The schema also provides a list of columns for identifying likely candidates for indexing.
Database schemas can be obtained from the underlying relational database, or can be obtained using the Omnidex Administrator program.
The table and column cardinalities help determine the best approach for Omnidex indexing. Tables cardinalities simply show the number of rows in each table. Column cardinalities show the number of distinct values in a column. For example, an INDIVIDUALS table may have a table cardinality of 300 million, meaning that there are 300 million rows in the table. The GENDER column may have a column cardinality of two, meaning that there are two distinct values in the column.
Cardinalities can be obtained from the underlying relational database, or can be obtained using the Omnidex Administrator after an UPDATE STATISTICS statement has been completed on a table.
Sample SQL queries are necessary to effectively determine the appropriate indexing strategy. Some designers may elect to index everything using Omnidex, but this may result in over-indexing, and it also doesn't insure that the correct indexing options are used on each column. It also does not insure that table joins and aggregations will be properly optimized.
The best approach to obtaining sample queries is to log the queries for an application for a period of time. Analyzing these queries allows the designer to understand the patterns of queries, and which types of queries are most common. It also reveals which queries tend to take the most time. Typically, a designer comes up with somewhere between 20 and 100 queries that are to be well optimized by Omnidex.
When analyzing SQL queries, there are several patterns to recognize:
After collecting this information, it is possible to develop an indexing strategy.
The actual techniques for optimizing designing the Omnidex indexing is discussed in the Omnidex Indexing topic.