Interest in NoSQL is on the rise and for good reason, traditional RDBMS systems have many strengths like ACID guarantees but they also have many weaknesses. The most associated trait of the NoSQL movement is the ability to scale writes and to a lesser extent reads (master/slave replication on RDBMS can handle high read requirements to a large extent). One of the often overlooked aspects in NoSQL is how well data maps into a non-relational store, but that is what I want to cover today.

In relational database design Database normalization is the recognized approach for schema design. A crude synopsis of Database normalization, is don’t replicate data. For example if you were designing a names and addresses, a fully normalized design would look something like this:

This will give you the data consistency you are looking for, so when Topeka changes it’s name to Google you are only updating one record. In the real world cities and states do not change their names very often, and a 4 table join to get the full contact information would have performance problems, so a selective Denormalization step would occur. The resulting database schema would look like this:

With a Document Oriented Database like MongoDB the Denormalization process would even go further and the address records would get embedded into the Person, resulting in one document. In order to show this concept more clearly, I will use the mongoid gem for ruby to create a Person and Address class. I then setup the associations using the has_many and belongs_to macros.

require 'rubygems'
require 'mongoid'

Mongoid.configure do |config|
  name = 'contacts'
  host = '192.168.1.19'
  config.master = Mongo::Connection.new(host, 27017).db(name)

end

class Person
  include Mongoid::Document
  field :first_name
  field :last_name
  has_many :addresses
end

class Address
  include Mongoid::Document
  field :street_number
  field :street_name1
  field :street_name2
  field :city
  field :state
  belongs_to :person, :inverse_of => :addresses
end

person = Person.new(:first_name => "Walt", :last_name => "Disney")
person.addresses << Address.new(:street_name1 => 'P.O. Box 10000',:city => 'Lake Buena Vista', :state => 'FL')
person.addresses << Address.new(:street_name1 => 'P.O. Box 10040',:city => 'Lake Buena Vista', :state => 'FL')
person.save

Once you run this program the resulting document is shown below.

  { "_id" : "4bb333c44954b30ff6000001", "first_name" : "Walt", "last_name" : "Disney", "_type" : "Person", "addresses" : [
    {
        "street_name1" : "P.O. Box 10000",
        "city" : "Lake Buena Vista",
        "state" : "FL",
        "_id" : "4bb333c44954b30ff6000002",
        "_type" : "Address"
    },
    {
        "street_name1" : "P.O. Box 10040",
        "city" : "Lake Buena Vista",
        "state" : "FL",
        "_id" : "4bb333c44954b30ff6000003",
        "_type" : "Address"
    }
  ] }

In many ways this is the feature of a NoSQL database that is most appreciated, the ability to more accurately represent real world data relationships in a natural manner. I would recommend you look at MongoDB, if you have similar data models.