Document Databases: Take Advantage of Simplicity and Productivity

Document Databases

First a brief overview

Document databases, or in other parlance NoSQL databases, offer an interesting opportunity for developers. In short, a document database is a key value store that offers the ability to loosely model data that does not require maintenance of associations; rather, a document database is mechanism that merely stores data and lends it self to horizontal scaling. Many times this will mean that querying and reporting will be more difficult than relational databases.

Despite this disadvantage of lack of robust querying capability, there are scenarios where storage and rapid availability trump the need for interrogation. Furthermore, complex object graphs with nested objects such as the one below are easily serialized, stored in a document database, and fetched back to the application.

public class Workflow
        public string Id { get; set; }
        public string WorkflowType { get; set; }
        public List<State> States { get; set; }
        public List<Trigger> Triggers { get; set; }
        public List<Transition> Transitions { get; set; }
        public List<StepCreationScript> StepCreationScripts { get; set; }
        public List<EditForm> EditForms { get; set; }
        public List<StatePermission> StatePermissions { get; set; }
        public List<string> Roles { get; set; }
        public List<string> Operations { get; set; }
        public string PreprocessFilters { get; set; }
        public string PostprocessFilters { get; set; }

While this may be a mere 12 lines, remember that each referenced class will be included in the object graph. Furthermore, in this case we make use of the List structure where there will be a variable number of child objects. The SQL needed to support your CRUD operations will certainly be complex. Yet another benefit that a document database can have is a significant reduction to the need for “plumbing” code to be written in order to save data. Since you can serialize an object directly and save it to the data store, you may eliminate the need for Data Transfer Objects, as serializing your domain objects may be sufficient for your application’s goals.

So you may be wondering what scenarios are best suited for a document database. For one, a workflow system that’s need to define workflow state, instance specific logic, data entry forms is a good choice, as evidenced by AprovaFlow. Another scenario is user profiles where you may store varied properties. Or perhaps system configurations.

For .Net: RavenDB

If you are looking for a product to run in the .Net world, RavenDB offers a robust choice. RavenDB offers many features that not found in MongoDB or CouchDB. These include Aggregation Streams, projections, flexible access authorization, dynamic document indexing for ad hoc query support, and set based operations.  RavenDB also offers a plugin architecture so adding addition features – “bundles” in RavenDB parlance – is extremely easy.

RavenDB stores data as JSON, and exposes this data via http as well as via a native .Net architecture. Using the .Net architecture enables developers to take advantage of current skill sets like LINQ and object orientated application design. If you adhere to the application principals espoused by the RavenDB development team, you eliminate the need for a repository pattern and can simplify data layer design. .Net Developers will very comfortable with RavenDB.

While architecting production ready applications is no simple, getting started with RavenDB is not arduous. A good primer for getting your feet wet is  ApprovaFlow: A Quick Primer On RavenDB. As with many technologies, RavenDB does offer its challenges. Creating indexes using Map-Reduce can be a challenge.

Something very different: Firebase

It may difficult to characterize Firebase as a document database, as it offers many different features aimed at boosting developer productivity. It does store data as JSON, so it is characterized as a key value store; however, Firebase will act as complete back end service for your application development. It offers real time synchronization, data security, and automatic scaling. Firebase supports web / javascript development, Node.js, iOS, Backbone.js, Angular.js, and has a REST architecture.

Out of the box Firebase provides authentication methods using GitHub, Facebook, Persona, and a tradition email / password combination. In addition to offering security features, Firebase inherently supports local data storage, transaction management, presence management. All data is written locally first, then deltas are fired up to the Firebase service.

One big different with Firebase is with filtering and querying – Firebase filters data by either location or priority. This means that the data for your applications will be denormalized. This is Firebase’s intent, as the goal is to support fast operations. The implication is that your data will be structured quite differently. While RavenDB allows you to index and include related documents, Firebase will force you to define top level keys as start points in your data structure, and then include data in the corresponding points of that data structure that is suited for fast retrieval. No walking the data structures. A good overview of this architecture is Denormalizing Your Data is Normal.

Take the next step:

Interested in consulting services or demonstrations?

ActiveEngine Software by ActiveEngine, LLC.