Fortsätt till huvudinnehåll

Some database theory

For reasons at work I am currently looking into how storing and retrieving data from databases works. Was introduced to an abbrivation that I didn't know of earlier, ACID. ACID is a combination of Atomicity, Consistency, Isolation, and Durability.

  • Atomicity - requires each transaction to be "all or nothing". A transaction may consist of several writes to the database, however, if any of these fail, or is interrupted, the entire transaction must be invalidated in order to have the database in a valid state.
  • Consistency - requires that any transaction will bring the database from one valid state to another. No transactions may currupt the database.
  • Isolation - ensures that concurrent transactions results in a system state that would be obtained if they were executed sequentially. Read that sentence again, it is a tricky one. Be able to perform concurrent transactions in a way that the result is like they have been done sequentially...
  • Durability - ensures that a transaction, once commited, will remain so even if the power is lost, something crashes, some other error occurs.
One technique for providing the A and D (atomicity and durability) is Write-ahead logging (WAL). With this tecnique all modifications to the database is written to a log before being applied. The log usually contains both redo and undo information. When recovering from a power loss the log can be compared to the actual contents of the database to determine where in the execution the power was lost. That information can then be used to determine if and how to roll back, finish any interruptad transactions, or leave the database in the state it was when the power was lost.

That pretty much sums up what I have been learning about databases today. More reading on the topic tomorrow (and hopefully some implementation).

Kommentarer

Skicka en kommentar

Populära inlägg i den här bloggen

C# Enum as bit field

Bit field enum Whenever you wish to express combinations of properties of an object, bit fields are a good way to accomplish this. As a simple example, consider a file in the file system. It can be Readable , Writable , Hidden or a combination these. The different attributes can be defined as an enum : [Flags] public enum FileAttribute {   None      = 0b0000;   Readable  = 0b0001;   Writeable = 0b0010;   Hidden    = 0b0100; } To indicate that this enum is expected to be used as a bit field I have defined it with the FlagsAttribute . It is important to understand that the FlagsAttribute does nothing more than making some changes to how the ToString method of the enum works, making it possible to print out all flags. It does not introduce any validation or special treatment of the enum in any other way. I have defined the values of the different fields of the enum using binary representation, this should make it even more clear that this is a bit field and which bi
Skicka en kommentar
Läs mer

Codility tasks - Part I

I was recently faced with two codility tasks when applying for a job as an Embedded Software Engineer. For those of you who arn't familiar with Codility you can check out their website here:  www.codility.com Task one - Dominator The first task was called Dominator. The goal was to, given a std::vector of integers, find an integer that occurs in more than half of the positions in the vector. If no dominator was found -1 should be returned. My approach was to loop through the vector from the first to the last element, using a std::map to count the number of occurences of each integer. If the count ever reached above half the size of the vector I stopped and returned that integer and if I reached the end without finding a dominator I returned -1. So was that a good approach? Well, the reviewer at the company rated the solution as 'pretty ok'. His preferred solution was store the first integer in the array and set a counter to 1. Then loop through the remaining i
7 kommentarer
Läs mer