Sunday, 3 March 2013

Data Stores

As always with me, the choice of data store is actually quite a difficult one. There are so many different choices these days, with different pros and cons between them. Ultimately in this case it came down to two different requirements:

  • Document Store or Relational Table Store
  • Transactional or Non-Transactional
The second one is actually tied to the first in this case. Transactional only matters if you are going to be updating multiple target records at a time. In a Relational Table Store this is almost certainly going to be the case, but in a Document Store you can architect it so that the single document you are storing contains everything so you don't need to do multiple-record updates.

The third, secret requirement actually narrowed the field even more. This is the fact that I must be able to use the store during unit testing - if it's not tested it doesn't work! - which removed a lot of the NoSQL field from play. For Relational Table Stores - i.e. SQL databases - I can use HSQL or Derby during unit testing for a representation of the final database, and likely PostgreSQL as the real production store. For a Document Store, MongoDB has a library somebody wrote to allow you to run an embedded version, which is perfect for unit testing. The library actually downloads, unpacks and runs MongoDB of the appropriate version for you to use, and tidies up afterwards.

I've actually chosen to go with MongoDB for this, in part because I've not yet successfully written a project with it (and I'm a glutton for punishment) and in part because I think the Document Store is actually going to be a good fit. It means, for example, I can store entire character details - their equipment, skills, stats, etc - as a single Document and not as details spread across many different tables. We shall see how it goes.

1 comment:

  1. I've been super happy with Postgres, using HStore if I need more open-ended storage for part of the data. I initially was using CouchDB for everything, but found that I had to write so much code to enforce certain rules (due to not having a schema) that the non-relational/document store ended up being a pretty big bummer.

    You don't need to write migrations with something like MongoDB or CouchDB, but I find that your code takes a hit in bloat and conciseness, since you're forced enforcing constraints within your application rather than having the DB do it for you.