Why use a database instead of just saving files?
Why not just save a file? Guess first, then see two users clash, a crash half way and an index that finds a row in 20 steps.
- 1Two writers can wipe out each other's change6 min
- 2A save can be cut short, and a transaction fixes that6 min
- 3An index jumps to the row instead of reading them all6 min
- 4Pick by what you need: a file is fine until it isn't5 min
Sound like you?
The ideas people most often get wrong on the way, in their own words. Each step starts from one of them.
The short answerRather read it than work it out?Show it (it gives the steps away)
Saving a value is three steps: read, change, write. If two processes both read 100, one adds 10 and one adds 20, then write, the file holds 110 or 120, not 130. The later write erases the earlier one. A database orders the changes with locks or transactions so none is lost.
A write takes many steps and can stop half way. Moving 50 from A (100) to B (0) takes two writes: if the crash comes between them, the total drops from 100 to 50. A transaction makes the steps all-or-nothing, and a database writes a journal so it can finish or undo the job after a crash.
Scanning checks rows one by one, so it takes twice as long for twice the data. At a microsecond a row, a million rows take about half a second on average. An index is sorted, so each step halves what is left: about 20 steps for a million rows, since 2 to the power 20 is just over a million.
A file is simple to run and to back up, and is a fair choice for one user, small data and few changes. A database earns its cost when there are many writers, data that mustn't be lost or half-saved, or heavy searching. SQLite gives transactions and indexes in a single file, which blurs the line.
Learn it with your own tutor.
Add it to your goals and Cognosc starts from what you already know, works through the rest with you, and keeps checking you still understand it.