Just recently, I am finding that I am using SQLite more and more often as the development database. There are a number of benefits using SQLite:
1. Portability
I can easily transfer the database around with my code. It is a single self contained file, I dont need to worry about the database engine configuration.
2. Source Control
As it is a self contained single file, the database can be placed into source control. Thus when you get a particular version of the code, out of source control, you also get the correct version of the database complete with data. You dont have to rebuild a database from script, including loading demo data.
3. Distributed development
Developers have their own copy of the database, they dont connect to a shared repository which might cause some problems if developers are making changes to the structure. Also, if developers are working remotely they may not be able to connect to the shared development database.
4. No local installation of a database engine
If you are like me, you will work on a number of different projects each of which connect to a different database engine (depending on client requirements). I dont like the overhead of running multiple database engines on my development machine.
Of course, when applications go into production you need to ensure you choose the correct database engine for your solution. Thus this type of solution is really only useful if you are using some type of database abstraction layer (such as hibernate).
How are you doing your development?
How do you manage version control of your applications database?
Leave me a comment below and let me know
Trackback URL for this post:
- dgrinberg's blog
- Login or register to post comments
Comments (1)
Storing the SQLite databases
Storing the SQLite databases in the repository has never been something I considered. I tend to store DB build scripts or schema's in the repository and rebuild the database if I need to start from scratch. Being a binary file putting the SQLite files in really seems lack a point for me as I can not track revisions to them and if your database is of any real size it will quickly inflate the size of the repository.
The framework I tend to work with allows for a quick build of the DB structure using the latest schema, and also includes seed files which will insert the static data (such as lookup data, etc) as well as the option to also include additional files with demo or sample data.