Sqlite como reemplazo para fopen ()?

Question

En una página web oficial de SQLITE3 Se escribe que debería pensar en SQLite como un reemplazo de la función Fopen ().

¿Qué piensa usted al respecto? ¿Siempre es una buena solución para repetir el almacenamiento de datos internos de la aplicación con SQLite? ¿Cuáles son las ventajas y los inmudos de dicha solución?

¿Tienes algo de experiencia?

EDITAR: ¿Qué tal su experiencia? ¿Es fácil de usar? ¿Fue doloroso o más bien alegre? ¿Te gusta?

Answer 1

Eso depende. Hay algunas contraindicaciones:

• Para los archivos de configuración, el uso de texto plano o XML es mucho más fácil de depurar o alterar que usar una base de datos relacional, incluso una tan liviana como SQLite.

• Las estructuras de los árboles son más fáciles de describir usando (por ejemplo) XML que mediante el uso de tablas relacionales

• La API SQLite está bastante documentada: no hay suficientes ejemplos y el hipervilizador es pobre. OTOH, la información está allí si quieres cavar por ella.

• El uso de formatos binarios específicos de la aplicación directamente será más rápido que almacenar el mismo formato que un blob en una base de datos

• La corrupción de la base de datos puede significar el LOS de todos sus datos en lugar de eso en un solo archivo malo

OTOH, si sus datos internos encajan bien con el modelo relacional y si hay mucho, recomendaría SQLite, lo uso yo mismo para uno de mis proyectos.

Con respecto a la experiencia: la uso, funciona bien y es fácil de integrar con el código existente. Si la documentación fuera más fácil de navegar, le daría 5 estrellas, ya que le daría cuatro.

Answer 2

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 ...).

Answer 3

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.

Answer 4

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.