This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
integration:rdbms:home [2011/03/15 20:16] els |
integration:rdbms:home [2016/06/28 22:38] (current) |
||
---|---|---|---|
Line 10: | Line 10: | ||
[[integration:rdbms:queries|Queries]] | | [[integration:rdbms:queries|Queries]] | | ||
[[integration:rdbms:updates|Updates]] | | [[integration:rdbms:updates|Updates]] | | ||
- | [[integration:rdbms:implementation|Implementation Guides]] | + | [[integration:rdbms:integration|Integration Guides]] |
---- | ---- | ||
==== Overview ==== | ==== Overview ==== | ||
- | Omnidex is often used to increase performance and improve flexibility on relational databases. Most companies that have invested in a relational database solution will continue to use the relational database as their core data store, but they may want to improve query performance or enhance their searches with [[admin:indexing:activecounts:home|ActiveCounts]], [[admin:indexing:powersearch:home|PowerSearch]] or [[admin:indexing:autocomplete:home|AutoComplete]]. Omnidex can access the data in the relational database and provide a high-speed query environment. | ||
- | Integrating Omnidex into an application environment usually requires integration in two areas: the client or application layer, and the server or database layer. | + | Omnidex is often used to increase performance and improve flexibility on relational databases. Most companies that have invested in a relational database solution will continue to use the relational database as their core data store, but they may want to improve query performance or enhance their searches with [[admin:indexing:activecounts:home|ActiveCounts]], [[admin:indexing:powersearch:home|PowerSearch]] or [[admin:indexing:autocomplete:home|AutoComplete]]. Omnidex can access the data in the relational database and provide a high-speed query environment. |
- | Omnidex applications often have tens to hundreds of indexes per table, delivering extremely high performance. As such, Omnidex is usually installed on read-only tables that are updated at periodic intervals. Omnidex does support online indexing; however, this is not suitable for high-volume OLTP applications. | + | One of the first decisions for the administrator is which tables Omnidex should access. Omnidex applications often have tens or hundreds of indexes per table, delivering extremely high performance. The overhead for real-time updates on hundreds of indexes can be substantial, and as such, Omnidex is not a good solution for indexing a high-OLTP system. If applications are going to heavily index the data, Omnidex should be pointed to separate tables that are periodically refreshed. If the data is not heavily updated or if the Omnidex indexing is minimal, then real-time updates remain an option. |
- | Some companies that use relational databases discover that Omnidex can also provide a complete SQL engine against [[integration:rawdata:home|raw data files]]. This introduces the possibility of creating an low-cost, high-performance, autonomous query environment used data extracted from the relational database on a separate server. This can alleviate the load on the relational database while improving performance and increasing scalability. This can also lower licensing costs for the overall application. | + | Omnidex is most commonly installed on read-only tables that are periodically refreshed. Some companies discover that Omnidex can also provide a complete SQL engine against [[integration:rawdata:home|raw data files]]. This introduces the possibility of creating low-cost, high-performance, autonomous query environments using data extracted from the relational database. These can be placed on a separate server, alleviating the load on the relational database while improving performance and increasing scalability. This can also lower licensing costs for the overall application. |