Last week I was involved in some design discussions around implementing/re-designing Dining and Entertainment pages for a star group of hotels.
CASE IN POINT:-
- The hotel wanted to revamp their Dining and Entertainment(D&E) pages by adding new content, type of content, layout of the page etc.
- The required layout was pretty simple with some normal stuff like title, introduction, detail description adding highlights section etc.
- As would be expected we did our due diligence in designing the RELATIONAL database tables and we came up with a NORMALIZED one to many model, the one that we are so used to doing, probably even with our eyes closed .
- No points for guessing what the tables might look like. Yeah you guessed it right we have a D&E table and a couple of tables to hold the association like Menu and Highlights.
DOING IT DIFFERENTLY: -
- The question to ask is do we really need relational database to structure something like this ? Some characteristics that might lead us to RDBMS are not required here viz:- no cross-references hence no normalization was required, entire page has to loaded always so no lazy loading a subset was required etc.
- The design was NOT extensible at all, Today we have tables with each of sub components like Menus, Highlights. Tomorrow if they decide to add another section to the page let's say "comments", we will all be scrambling our way to add another table in the database and link it with the existing D&E tables.
- We are probably trying to store un-structured components of a document as relational entities, so why not use a Document Oriented Database? Some characteristics of Document Oriented Database are: -
Documents (objects) map nicely to programming language data types
Embedded documents and arrays reduce need for joins
Dynamically-typed (schema less) for easy schema evolution
No joins and no (multi-object) transactions for high performance and easy scalability
- Enter MongoDB(http://www.mongodb.
org/display/DOCS/Schema+Design ). It is no-sql database and is riding high on the waves of popular sentiment after the success of likes of Cassandra, Hadoop etc. - In MongoDB we could have stored the contents of entire page as a collection of documents structured as json, where each sub-document is free to extend it self and adding another section to a page would be breeze, it would just involve adding sub-document to the already existing tree of document with D&E as its root. No joins required to read the document leading to optimized data access layer.
- And to top it all, MongoDB very well supports all of, concurrent reads and writes, replications, failover, sharding etc. etc.
- For all those spring lovers there is also a sprint project which makes reading and writing to MongoDB fairly simple. It is called spring data and can be found here (http://www.springsource.org/spring-data)
Cheers!
