This post is my response to Jon Reed's article on Marriott's switch from stone age crazy expensive databases, to raindance-age nosql, with false claims of leapfrogging open source sql relational database technology. Hi Jon, Thank you for the excellent glimpse into the nosql world and it's value proposition. This is my ignorance exposed: I saw that companies are making it work. I did not see any benefit over open source rdbms. The guy at Marriott said nosql provides an easy path from Java objects to the database. That is an ignorant statement. There is no path from Java objects, or any other objects, to data bases and back that is easier with nosql than with open source rdbms. At best, the path to nosql data can be as direct and simple, but it is not possible to make a connection to data more simply than an rdbms can provide. Mr. Vidnovi also referred erroneously to overhead of rdbms technology being more than the overhead of nosql. By the time you consider all the elements tosuppory support nosql, not just the couchbase. Vs. Rdbms software, to include support for a complicated file system, petformance-enhancing mechanisms to keep response times good, an architecture or standards for keeping your company's implementation manageble, the best you are going to get for overhead is a solution as good but no better than what you could get with an rdbms. You might get a nosql solution better than a sub-optimal rdbms, but there is no potential with nosql to outperform a well implemented rdbms. This applies to every benefit of nosql attributed to of Mr. Vidnovic in your article. The comments by couchbase CEO Michael Wiederhold explained how success is possible with nosql, but there was no claim of advantage using nosql instead of an rdbms. The reason Mr. Vidnovic is is excited about that Nickel package, is its likeness to sql. Just as the Arabic number system is way good enough for meeting our mathematical needs, sql and the relational data model is way good enough, and at least as good as any other scheme yet devised for working with data. Math based on nines or elevens can potentially work exactly as well, but not better than math based tens, but why bother, when the human race has so much invested in using tens? I'll tell you why: you know those T-shirts that say, "If you cannot dazzle with brilliance,you can baffle with bull snot?" I just made that up, but would you prefer the orignal? Nines and elevens cannot work better than tens, and nosql cannot work better than sql. I have no problem standing corrected. It's not like I know everything. I am looking forward to responses more informed than mine. ."
Dan thanks. I do stand by the reporting in this article, in that I quoted the views of Marriott accurately. This article is of course 15 months old. You raise some good points about open source SQL. I don't have a dog in this fight - I'd prefer customers to have the widest range of choices and know-how, including open source. As you know some companies are still reluctant to pursue open source projects but I do my best to document the value achieved from those also. Next time I get the chance to talk to Marriott on this I will get an update on how their project is going but not sure when that will be. In general you are raising the right questions, customers should think about all the choices available to them, including open source options. There really isn't a one size fits all solution and as you point out, sometimes the most cost saving option can have hidden costs etc. In general the distinctions between NoSQL and SQL are getting smaller as database companies look to round out their offerings. It's important not to buy into the hype. But when I get a chance to share a customer story, I will - whether it's SQL, NoSQL, open source SQL, or some combo of these. Usually it comes down to a particular use case - there is no solution that works in all cases. For the record I was not compensated by Marriott or Couchbase, it was an interesting project to write about and if I write an update later on I'll let you know. Thanks for the comments.
