Wiki: https://landing.athabascau.ca/pg/pages/view/130277/couchdb

Report: https://landing.athabascau.ca/pg/blog/read/131228/report-potential-improvement-using-nosql-solutions-on-apartment-rental-system

Bookmark Item #1: https://landing.athabascau.ca/pg/bookmarks/read/129336/overview-of-nosql

Bookmark Item #2: https://landing.athabascau.ca/pg/bookmarks/read/130036/12-top-big-data-analytics-players

The lesson learnt from the research in week 9 really opens up the possibilities to employ schemaless databases for less control and restrictive applications. For a long time, relational databases seem to be the only choice as a reliable solution. The NoSQL movement brings the non-relational databases into the spotlight especially the endorsement of many well-known companies such as Forbes (MongoDB), Amazon EC2 and S3 (SimpleDB) and Cassandra (Facebook). Some of the NoSQL includes Document Store DB, Key-Value Store DB, Graph DB, Object DB, etc. Some db type works better than others due to the architecture model. For instance, Twitter uses FlockDB that implements the graph DB model, efficiently aligning its business focus with the innate framework of a graphDB model given that Graph DB stresses on relationships (edges) rather than entities (nodes). 

Upon further considerations, I have decided not to use NoSQL alternatives and keep the current RDBMS (MS Sql Server) implementation for my Apartment Rental System for the following five reasons.

Full ACID Support: The use cases I envision for the Apartment Rental system involves concurrent read and update scenarios that require the option to specific pessimistic locks on table or rows while only optimistic locking is supported in some NoSQL flavor such as MongoDB. This is needed in cases where executive reports are required to be produced with 100% consistency with the most committed up-to-date information. Also, the use cases favor strong consistency rather than weak consistency that NoSQL offers.

Referential Integrity: Ensuring no orphan records are left standing is a critical requirement for my system. I would prefer to enforce these types of data integrity at the db level rather than bubble up the responsibilities to the application level.

Rigid DB Structure: The data attributes are clear and well-defined in my scenario and no loosely relationships exist in my case. Therefore, the relational tables are best used in my situation where there is no high level of ambiguity. This ensures data integrity which is a highly desirable feature by the relational db model.

Compatibilities: Rational db model is a tried and true db model that works with many design tools already in the marketplace. These tools have been refined and bundled with advanced features that NoSQL tools might lack. This is also important from a productivity standpoint to tap into an already existing large pool of IT professionals for the construction of my system.

All in all, the advantages that NoSQL offers does not apply in my scenario. The system I envisioned is highly transactional rather than analytics, highly structured rather than loosely defined, low data volume rather than massive in data size. With the understanding I now equipped with NoSQL, the decision to go for cloud or private hosting does not endorse or deter the use of RDBMS since cloud database services support both relational and non-relational data model albeit the cloud environment is more conducive for NoSQL. Therefore, with the kind of relatively low data volume and the ease of management of cloud db service, I now set my eyes on Microsoft SQL Azure service.

For five reasons (Analytics, Scale, Redundancy, Flexibility and Rapid Development) why IT professional should consider NoSQL, see the facility9.com in the reference section.

References:

http://www.mongodb.org/display/DOCS/Production+Deployments

http://wiki.apache.org/couchdb/CouchDB_in_the_wild/

http://facility9.com/2010/09/five-reasons-to-use-nosql/

Dickson