This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
integration:rdbms:updates [2011/03/14 19:20] 127.0.0.1 external edit |
integration:rdbms:updates [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:creation|Generating Data Files]] | | + | [[integration:rdbms:integration|Integration Guides]] |
| - | [[integration:rdbms:implementation|Implementation Guides]] | + | |
| ---- | ---- | ||
| - | ==== Updating Raw Data Files ==== | + | ==== Updating Relational Databases ==== |
| - | Omnidex allows raw data files to be updated with some limitations; however, the large majority of Omnidex applications simply replace some or all of the data files and reload the Omnidex indexes. Raw data files are usually used for Omnidex Snapshots, data warehouses, data mines, transaction logs, or regularly-replaced data files. In these situations, it is easiest and quickest to simply replace the data and update the indexes. | + | Omnidex is most commonly implemented on read-only tables. Many Omnidex applications take advantage of tens to hundreds of indexes per table, and online updates are impractical in this situation. Omnidex applications are usually built around tables that are refreshed on a daily, weekly or monthly basis. Once the data has been updated in the relational database, the indexes are refreshed using the [[dev:sql:statements:update_indexes:home|UPDATE INDEXES]] statement. Omnidex can quickly build all of the indexes at once, allowing the freshly indexed application to be deployed. |
| - | Some applications may wish to use the SQL INSERT, UPDATE and DELETE statements to update raw data files. Different types of raw data files have different support for updates. These capabilities are shown in the table below: | + | Omnidex also supports real-time updates using the SQL INSERT, DELETE and UPDATE statements. These statements will update both the underlying relational table and the Omnidex indexes. This approach is appropriate for tables with a low volume of updates, or for tables with minimal indexing. |
| - | ^ File type ^ INSERT ^ UPDATE ^ DELETE ^ | + | Omnidex's INSERT, DELETE and UPDATE statements do not support transaction management or isolation levels. Each INSERT, DELETE or UPDATE is considered a transaction unto itself. Both data and indexes are visible to all users as soon as they are made. |
| - | | Fixed-length data files | Yes | Yes | No | | + | |
| - | | Delimited files | Yes | No | No | | + | |
| - | | Omnidex Standalone Tables | Yes | Yes | Yes | | + | |
| - | + | For Oracle and SQL Server databases, Omnidex allows the indexes to be updated by relational database triggers using [[dev:programs:odxaim:home|Automatic Index Maintenance]]. Triggers are installed on each table that posts update transactions to a common log file. A separate process reads committed transactions from this table and posts them to the Omnidex indexes. This approach allows Omnidex to capture committed updates from all sources without changing those aspects of the application. At the same time, it does introduce a delay between the change to the data and a change to the indexes. This delay can vary depending on the volume of updates and the number of indexes. | |
| - | Like most NoSQL databases, Omnidex does not support transaction management. Each update operation is treated as a transaction of its own, and it is not possible to group multiple update operations into a single transaction. | + | |
| - | + | ||
| - | Referential constraints are often declared in Omnidex Environment Files, and these are used by Omnidex when optimizing queries. Omnidex does not enforce these constraints during update operations, and so the application or the administrator must insure referential integrity exists between tables. | + | |
| ===== ===== | ===== ===== | ||
| **[[integration:rdbms:queries|Prev]]** | | **[[integration:rdbms:queries|Prev]]** | | ||
| - | **[[integration:rdbms:creation|Next]]** | + | **[[integration:rdbms:integration|Next]]** |
| ====== Additional Resources ====== | ====== Additional Resources ====== | ||