This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
admin:basics:updates:triggers [2011/04/12 18:12] doc |
admin:basics:updates:triggers [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 16: | Line 16: | ||
| ==== Triggered Updates ==== | ==== Triggered Updates ==== | ||
| - | Omnidex allows some relational database to use triggers to send INSERT, DELETE and UPDATE requests to Omnidex. 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 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 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. |
| 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 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. | ||
| + | |||
| + | 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. | ||
| ==== ==== | ==== ==== | ||