Today’s random terminology is: atomicity. This term is used specifically within the database design realm. Other ways of referring to atomicity are: atomic (adjective) and atomic transaction (noun).
An atomic transaction is an update transaction within a database that will either complete fully or have no effect at all. Atomicity is the guarantee that all update processes within a database will follow that rule: complete or nothing. It’s similar to the sayings: all or nothing and go big or go home. An atomic transaction is either done correctly or it doesn’t occur.
This may be a little awkward to picture without an example. Let’s say we’re in charge of designing and administering the MLB’s databases. When it comes to individual players there are a wide variety of table but specifically we’re looking at the salary table and the roster table. Within the salary table is a listing of every player ID and the salary they’re earning. Within the roster table is a listing of every player ID with the team ID they belong to. Simple enough.
What happens when a player changes teams? Well you’d update the roster table. But a team change could come with a salary change (99 out of a 100 times it will). We don’t want to update the player’s team but keep their old salary. Both actions must occur or the update process has failed and we need to reexamine it. As such, an atomic transaction in this case would be one where both tables are updated successfully. For this situation to follow the rules of atomicity, that transaction must fail if one table cannot be updated.
I’ll go into this more within another article, but atomicity is actually one of four properties that must be present to ensure reliability within a database system. These properties are known as ACID (atomicity, consistency, isolation and durability).