Non-Relational Database Design
- by Ian Varley
I'm interested in hearing about design strategies you have used with non-relational "nosql" databases - that is, the (mostly new) class of data stores that don't use traditional relational design or SQL (such as Hypertable, CouchDB, SimpleDB, Google App Engine datastore, Voldemort, Cassandra, SQL Data Services, etc.). They're also often referred to as "key/value stores", and at base they act like giant distributed persistent hash tables.
Specifically, I want to learn about the differences in conceptual data design with these new databases. What's easier, what's harder, what can't be done at all?
Have you come up with alternate designs that work much better in the non-relational world?
Have you hit your head against anything that seems impossible?
Have you bridged the gap with any design patterns, e.g. to translate from one to the other?
Do you even do explicit data models at all now (e.g. in UML) or have you chucked them entirely in favor of semi-structured / document-oriented data blobs?
Do you miss any of the major extra services that RDBMSes provide, like relational integrity, arbitrarily complex transaction support, triggers, etc?
I come from a SQL relational DB background, so normalization is in my blood. That said, I get the advantages of non-relational databases for simplicity and scaling, and my gut tells me that there has to be a richer overlap of design capabilities. What have you done?
FYI, there have been StackOverflow discussions on similar topics here:
the next generation of databases
changing schemas to work with Google App Engine
choosing a document-oriented database
