Jose: Hi, guys and welcome back.
Before we start working on the project,
we need to talk about what is ACID?
And ACID is something in databases, nothing illegal,
and it stands for Atomicity, Consistency,
Isolation, and Durability.
We've discussed before that SQL operations occur
in transactions.
So, are transactions ACID?
And the answer to that is not really,
although they are a result of ACID,
or, rather, in order to be ACID, we must use transactions.
There's no way around it.
Here's why, the first letter in ACID is Atomicity,
and that means that transactions are indivisible.
Every operation must happen successfully
in a transaction or none do.
Essentially, what Atomicity means
is that you can't divide the unit of work.
And here, the unit of work must be a transaction
because if you want to group to operations
that depend on each other, you must be able to do that
without being able to run one, but not the other.
So, for example, if you try to UPDATE and INSERT
in the same transaction, then you must be able to do both.
And if one fails, then the other one is rolled back,
or just ignored.
This is what Atomicity means.
For Consistency, this means that the rules and constraints
of the database are followed at all times.
For example, with foreign key constraints,
you can't have a foreign key pointing
to a non-existing primary key value.
We've learned about this in Postgres
when we had users and bank accounts.
You couldn't delete a user,
but keep the user's bank account
because that was an inconsistency in the data.
There are more constraints than just foreign keys though,
such as UNIQUE constraints, or NOT NULL, and many more.
We're going to learn about those constraints later on.
Isolation means that data is only visible in the database
when the transaction has ended and been committed.
For example, if one transaction makes 10 INSERTs,
the other transactions won't be able to see any of that data
until the first transaction has been committed.
That means that transactions are essentially isolated.
They work on the database as it exists
at this point in time, but they don't see the results
of any other transactions until they have been committed.
Durability means that data is saved to permanent storage
once a transaction is committed.
So, this is in contrast to some other database systems
that operate either partially or fully in memory.
Operating in memory is faster, but it's also a bit riskier.
For example, there's databases
that hold a lot of the results in memory,
and they only save to disc every now and then.
And if you use a database like that,
it's gonna be much faster.
You can write and read from that memory data very quickly,
but if your database server crashes,
you might lose some work.
The Durability aspect of ACID means that SQL databases,
or databases that follow these ACID properties,
will always save to permanent storage
once a transaction is committed.
Remember, if you join this with Isolation,
then it makes sense to start committing transactions
all the time, otherwise the transactions
that aren't committed don't make the data available
to other transactions,
which means that other transactions can't work
with that data, and so on.
So, you want to be committing your transactions consistently
as that saves them to permanent storage,
you can't lose your work, and also makes the data available
to other transactions as well.
So, as I mentioned down below, you can use a database
that operates in memory for things
that you don't really mind losing,
like, for example, cash data
or the logged in status of users.
If the data for logged in status is lost,
the users may need to log in again,
but it's not a massive deal.
Whereas, for most of the other data, you do want to keep.
All right, guys, thank you for watching this video.
I hope you understand a bit more about what ACID is.
I'll see you in the next one.