This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
admin:basics:updates:triggers [2011/04/12 18:02] doc created |
admin:basics:updates:triggers [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 16: | Line 16: | ||
| ==== Triggered Updates ==== | ==== Triggered Updates ==== | ||
| - | Omnidex allows databases to be updated either in batch or online. The large majority of companies choose to update their databases in batch, and this is in keeping with the design of Omnidex and the nature of large databases. | + | Omnidex allows some relational databases to use triggers to send INSERT, DELETE and UPDATE requests to Omnidex. A database trigger is a set of instructions that are executed every time the database experiences an insert, delete or update operation. For Oracle and Microsoft SQL Server, Omnidex allows triggers to be installed on a table that copy changes to a separate transaction table. The [[programs:odxaim:home|OdxAIM program]] can generate these triggers for tables with Omnidex indexes. These triggers log the changes to the data in a separate, intermediate transaction table, and then OdxAIM processes this transaction table in the background to update the Omnidex indexes. This approach preserves transactional integrity, though there is a short delay between the updates of the database and the indexes. |
| - | Omnidex specializes in very large databases that are heavily indexed. This combination is more and more common in the industry as companies require increasing intelligence gathered from larger and larger databases. The classic approach of inserting data into a database simply doesn't scale well. Most relational databases can support inserting hundreds of thousands of rows into a table, but not hundreds of millions. If the database is heavily indexed, the classic approach of inserting data into a database falters even more. Most administrators would be understandably reluctant to insert hundreds of thousands of rows into a table with tens or hundreds of indexes. | + | This triggered approach is appropriate for a low volume of updates. Relational database triggers will require additional resources from the database, as will the logging and processing into the transaction table. This is in addition to the resources required to update the Omnidex indexes, as discussed in [[admin:basics:updates:online|Online Updates]]. This approach is not recommended for large volumes of updates. |
| - | This has led to new approaches to handling large volumes of data. Companies frequently process their data in larger batches, and Omnidex specializes in this approach. In contrast to the relational database, Omnidex is designed to regenerate all of the indexes on a table with a single scan of the data, processing rates of 1 billion index entries an hour<sup>,,1,,</sup>. [[admin:features:grids:home|Omnidex Grids]] also allow new nodes to be created and indexed independently from the rest of the database, allowing an incremental approach to updating the database. While it is impractical to drop and recreate large indexes in a relational database, it is fast and easy to regenerate the indexes with Omnidex. | + | The primary advantage of this approach is that it captures all updates to the database, regardless of the source of the update. Normally, all applications that update the database must be changed to route updates through Omnidex; however, triggers allow updates to be processed without an Omnidex connection. |
| - | + | ||
| - | For applications that require online updates, Omnidex supports the INSERT, DELETE and UPDATE statements and will update most kinds of Omnidex indexes in real time. Omnidex also supports an approach that uses triggers on relational databases to automatically capture all updates. Online updates have some [[admin:basics:updates:online|important restrictions]] that must be considered, but they can provide important flexibility to application designers. | + | |
| ==== ==== | ==== ==== | ||
| - | |||
| - | ---- | ||
| - | <sup>,,1,,</sup> ,,An "index entry" represents an indexed column in a single row. If the column contains textual data that is indexed with QuickText or FullText indexes, then an "index entry"" represents a single word or number in an indexed column in a single row.,, | ||
| **[[admin:basics:updates:grid|Prev]]** | **[[admin:basics:updates:grid|Prev]]** | ||