Re: Reliability of small database system
- Posted by jimcbrown (admin) Sep 29, 2013
- 5662 views
My original post didn't specify human readability as a requirement, true. However, it is something that I want
No problem. Out of curiosity though, why?
and could be related to reliability and error detection (correction). In other flat-file systems that I wrote any significant data corruption is detectable (a hash value on each line will pinpoint the problem area) and the user has the option to actually open the database file in notepad for review/repair.
Thinking it over, I realized that it's possible to have the best of both worlds with sqlite. You can create the database, then dump it into a text file when you're done. Later, recreate the database from the text file for the next use and dump it into the original text file when finished. So you keep and use the text file (which is a script that contains human readable commands to recreate the database, tables, data, etc) as the location where data is saved instead of using a binary sqlite database file for this.
The text file will take up more space, so this isn't practical if your database is too large. Also, you lose some efficiency on loading/saving data. Still, if having stuff saved in human readable text is that important to you, or you believe that having human readable text is more reliable/less prone to corruption than the binary sqlite format (I honestly have no idea whether or not this is the case), then this might work out.
(To save time on loading, you could keep the binary sqlite file around too and just use it directly, but simply write out a new text file when saving data. Presumably, if it's corrupt, you simply won't be able to open it and can then recover data by recreating it from the text file. Likewise, for extra reliability, you could save off the old text files or archive them somewhere (instead of overwriting them) before dumping the database into a new text file.)
