Professor Alan Fekete from the School of Information Technologies says there are always trade offs with designing database-backed systems, and operational glitches are always a risk. But he says data corruption needn't cripple a company's entire transaction system.
"Database systems have mechanisms to keep backup copies, and a log or audit trail of what is happening. However, when something goes wrong, these systems can need time to recover the correct state, and during this time the database will be unavailable. It is important for a customer-facing enterprise to keep operating in these situations, while the database is being recovered.
"It's possible to remain viable once a computer glitch kicks in by using a variety of hardware and by keeping records so you can untangle problems after the event," he says.
"Systems should ensure availability and sensible results, even while data is not completely consistent.
"For instance, important data can be stored in multiple places. This means when one machine crashes, or one copy of data is corrupted, then you can find some slightly obsolete version of it somewhere else. You can design the programs so that they keep processing customer requests, using old versions of data, as long as you're keeping robust records of all transactions until the problem is resolved.
"Proper data management stays operational and ensures an audit trail. In this case the system stopped operating when a file became corrupted, suggesting an oversight in the design of the wider IT systems."