tags:

views:

566

answers:

4

On an official sqlite3 web page there is written that I should think about sqlite as a replacement of fopen() function.

What do you think about it? Is it always good solution to replece application internal data storage with sqlite? What are the pluses and the minuses of such solution?

Do you have some experience in it?

EDIT: How about your experience? Is it easy to use? Was it painful or rather joyful? Do you like it?

+8  A: 

It depends. There are some contra-indications:

  • for configuration files, use of plain text or XML is much easier to debug or to alter than using a relational database, even one as lightweight as SQLite.

  • tree structures are easier to describe using (for example) XML than by using relational tables

  • the SQLite API is quite badly documented - there are not enough examples, and the hyperlinking is poor. OTOH, the information is all there if you care to dig for it.

  • use of app-specific binary formats directly will be faster than storing same format as a BLOB in a database

  • database corruption can mean the los of all your data rather than that in a single bad file

OTOH, if your internal data fits in well with the relational model and if there is a a lot of it, I'd recommend SQLite - I use it myself for one of my projects.

Regarding experience - I use it, it works well and is easy to integrate with existing code. If the documentation were easier to navigate I'd give it 5 stars - as it is I'd give it four.

anon
Badly documented? I think it's really good compared to other FOSS projects. They list pre- and postconditions for everything, and I haven't had any trouble understanding the API - with one exception. (One of their postconditions has a nice little "todo" note that they need to determine what it does)
jalf
About database corruption, you could just split your data into separate databases. Corruption of your own files would be just as bad - and more likely to happen. Databases are designed to be robust and stay consistent, after all.But I agree with your general point.
jalf
@jalf there are almost no examples - the cardinal sin for me as far as documentation goes. Also the hypertext linking is extremely poor.
anon
+2  A: 

The atomicity of SQLite is a plus. Knowing that if you half-way write some data(maybe crash in the middle), that it won't corrupt your data file. I normally accomplish something similar with xml config files by backing up the file on a successful load, and any future failed load(indicating corruption) automatically restores the last backup. Of course it's not as granular nor is it atomic, but it is sufficient for my desires.

AaronLS
True, try the 'correct' way of making a backup of an existing datafile and writing the new one in such a way that you can't fail at any point.
Martin Beckett
What would be the "correct" way in your opinion?
AaronLS
+4  A: 

As always it depends, there are no "one size fits all" solutions

If you need to store data in a stand-alone file and you can take advantage of relational database capabilities of an SQL database than SQLite is great.

If your data is not a good fit for a relational model (hierarchical data for example) or you want your data to be humanly readable (config files) or you need to interoperate with another system than SQLite won't be very helpful and XML might be better.

If on the other hand you need to access the data from multiple programs or computers at the same time than again SQLite is not an optimal choice and you need a "real" database server (MS SQL, Oracle, MySQL, PosgreSQL ...).

Nir
+1  A: 

I find SQLite a pleasure to work with, but I would not consider it a one-size-fits-all replacement for fopen().

As an example, I just wrote a piece of software that's downloading images from a web server and caching them locally. Storing them as individual files, I can watch them in Windows Explorer, which certainly has benefits. But I need to keep an index that maps between a URL and the image file in order to use the cache. Storing them in a SQLite database, they all sit in one neat little file, and I can access them by URL (select imgdata from cache where url='http://foo.bar.jpg') with little effort.

Enno