Troubleshooting Your Own Computer

Choosing Between Non-Transactional And Transactional Databases

by Dora Barrett

When setting up a database for your organization, you'll be confronted with the choice of setting up the database as a transactional or non-transactional database. These two database types are critical, as it will have an impact on how your applications are programmed and how your staff members interact with the database. 

Transactional Databases Can Be Rolled Back

The benefit of the significant resource and development costs is that a transactional database is ultimately more accurate. When applications are programmed for a transactional database, they are programmed to check for errors and roll back as needed. Rolling back a series of transactions essentially resets the database to before the error occurred. Without this type of transactional support, an error can occur in one query but the other queries can go through, creating an inaccurate database.

Transactional Databases Require Additional Resources

Transactional databases have to store a series of database changes in order to be able to roll them back. When transactions are being done one at a time, this isn't a significant issue. But when transactions are occurring from many individuals at once, this can create a substantial system overhead. Systems that have a transactional database will need to have better processors and more memory. 

Transactional Databases Are More Complex

A transactional database is more complex to develop for and to maintain. The programming involved is more complex because it has to compensate for the need to potentially rollback or commit transactions, so there may be more time in development. Employees may also need to be trained to work with a transactional database, as non-transactional databases are generally more common. If a programmer has to optimize the database, it may also take a specialist.

Transactional Databases Won't Store Inconsistent Data

In addition to being able to rollback changes, a transactional database won't leave a database in an inconsistent state. As an example, $50 might be taken from one client account to another. If an employee loads the database during this transaction in a non-transactional database, they could load it after $50 has been taken from the first client but before it has been given to the second client. In a transactional database, this will never occur.

In simplest terms, a transactional database is going to be much more accurate and secure but require more by way of setup and maintenance. With a reliable DBA remote support system, it may be feasible -- but for smaller businesses, it may not be possible. For more information, contact companies like Famsoft.