There's one last set of concepts I'd like to cover before we move into some
actual programming and this is ACID.
Now again, like many of the concepts in this lecture this is a very,
very broad topic and we're just barely going to scratch the surface.
But I want you to be familiar with these concepts because this is the type of
language we'll be using when we're building our system.
So, ACID, this stands for, A for atomicity,
C for consistency, I for isolation, and D for durability.
Atomicity refers to the notion that all parts of a transaction succeed or
fail together, Now, we haven't talked about transactions.
But these are basically just a group of statements.
So if we were updating our database which is actually not something
we spent much time on.
There maybe the case where updating two tables at once or
updating multiple rows in our database together, in one cohesive unit.
For example, if for
working from the written example if we had a link table and user's table and
somebody upvoted on the link and that increases the user's reputation.
In that increase the score of the link and
also increase the reputation of the user.
And those would happen in something that's called a transaction,
which groups together multiple commands.
Atomicity refers to the notion that either all of those commands
are going to succeed, or they're all going to fail.
But we don't do part of it.
We don't have just updating the link and
not updating the user, everything happens together.
So this is a nice property for a database to have.
Consistency refers to the notion that the database will always be consistent.
And to work from our Reddit example,
let's talk about this idea where we have a link and a user who have properties.
If we have this notion that a link has a score that gets
updated periodically, and the author or the submitter of that link
also has a karma score that also gets updated at the same time.
Consistency refers to the notion that both the score and
the karma will be consistent with one another, so
that we don't update the score without also updating the karma.
Basically means the database will move from one valid transaction to the next
so we'll never run a query that gets a link's updated score but
can't also get the user's updated karma.
So isolation refers to the notion that no transaction can interfere
with another.
So let's say we a link that is both getting,
two votes coming at the same time to increase the score of this link.
That means we're going to be updating the link score up and down, and
the user's karma up and down.
And isolation refers to the notion that this
upvote won't affect the computation of this downvote.
If we were overriding this link in our database,
it would be a shame if that downvote was applied to the original link's score
before the upvote was applied.
Because the net score change in here should be zero, but
it could be negative one if these aren't handled properly.
So, isolation refers the notion that each transaction cannot affect
other transactions.
Sometimes this is accomplished through locking.
If two transactions affect the same row, only one can go at a time,
and there are other ways of resolving transaction and conflicts like that.
Isolation refers to a database's ability to do that.
Finally, we have durability.
Durability refers to notion that once a transaction is committed it
won't be lost.
This means that for example if we send an update to our database and
we update some rows and the database says okay successful.
That even if the database is turned off or crashes or
is unplugged we won't lose that data.
That is durability.
One thing, I'd like you to know, I know we introduced a lot of new concepts
in this portion here, but the important takeaway from this,
is that when you're talking about different database systems,
that you have different trade offs.
It's hard to be fully, have a database that's completely atomic,
that's completely consistent.
All transactions are isolated and is completely durable.
There is always some trade-offs.