March 8, 2008

The Database Irritating Inconvenience

It’s already the second or third time in my career that I encounter problems introducing a database server for object persistence from the begininng. Unfortunately in the last project I arrived too late to stop the pervasive architecture that was taking over. The problem manifests itself as long and frustrating sessions to solve deploy problems, locally or on the continous integration server or the test environment. The symptoms are:

  • People need  to set up different credentials to access the database or there are environment contraints that force different roles
  • Developers want or are forced to use different names for their database locally
  • The need to create different database instances cloning schemas and creating related scripts (unit tests wipe out the database for each tests, acceptances do not)
  • The problem that slightly different flavors of the operating system affect the way the development database is installed and accessed
  • A new developer joining the team is forced to install a local database server and follow a complex procedure to setup it correctly based on the team settings.

Having this decision made up-front can deeply impact delivery of business values.

But is a customer constraint! 

Let’s assume that the customer wants to see a database in place or change the data in the application using the database as the main interface from the beginning. Even in this case, the requirement of the customer should not interfere with development decisions. Embedded databases are fine, file system persistence is too. Xml based persistency maybe. But you should remove as fast as you can the constraints to use a specific service from the development environment especially if this service is fragile, unreliable or hard to maintain because is network based. Do you remember the first rule of distributed computing? Don’t do distribute computing.

So How?

When it’s time to have object to persist, you just need to create an ObjectStorage object or you name it, something that can accept an object instance and make it persistent. If you’re testing when you need the storage to be in place, just mock the ObjectStorage to return the list of objects you need for your test to pass. This storage is just an object abstraction of what a database will look like. At some point in time you’ll need to give the storage a real implementation and at this point, use the best tool for the job. A database server with relative client APIs is usually overkill because it produces an external depencies on the operative system and consequentely a maintenance hassle. An embedded database is better, especially if can store in-memory. Because also files suffer from the same problem: they are external dependencies on the operative system. At some point you will need to switch the developement view of the database with a real database server. Well, of course some work needs to be done, but it’s required only for the test environment and production environement. You don’t need to do the same for the CI box or the local development workstations.

Conclusions

Resist the temptation to clone the development environment exactly like you think it should be in production. In production you don’t have mutiple development workstations, you don’t have a continous integration running and it’s the only place together with the QA environment where you really need to show the architecture the customer wants to see.