Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

When in the design phase do you start thinking NoSQL

 
Arun Radhakrishnan
Greenhorn
Posts: 7
Eclipse IDE Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

When thinking about organizing data, there is always a schema to start with. But as more changes come in, there is a pain point when you or the team realizes you have to go in and change the schema that you have in production or that given the new requirement the existing schema needs a total makeover. Are there some principles that can guide to a NoSQL solution from an early stage ? Or even some data specific guidelines that can make one pick a NoSQL solution much earlier in the development cycle ?
 
Martin Vajsar
Sheriff
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Arun Radhakrishnan wrote:When thinking about organizing data, there is always a schema to start with. But as more changes come in, there is a pain point when you or the team realizes you have to go in and change the schema that you have in production or that given the new requirement the existing schema needs a total makeover.

In my opinion, this alone is not at all an argument to favor NoSQL DBs over RDBMS (or the other way around). Schemas evolve much in the same way applications evolve. It is by no means an easy task to change schema that is deployed to production(s), but it is nevertheless happening all over the place in corporate domain. And some databases even allow an online schema redefinition to be performed, eliminating or greatly reducing needs for lengthy outages while a redefinition of largish tables takes place.

I would aim for a NoSQL solution from an early stage if I wanted to implement projects that can use its strengths. To the best of my understanding, NoSQL can handle efficiently tremendous volumes of data, usually at the expense of consistency or down-to-the-last-byte accuracy. If that fits you, go for NoSQL. If you're designing an accounting system for a bank, better stick to the RDBMS
 
Arun Radhakrishnan
Greenhorn
Posts: 7
Eclipse IDE Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would beg to differ Martin.

From the limited idea I have on NoSQL, one advantage was that you could effectively add new data ( change schema ), and still all your existing data did not require any upgrade. I think I read this in the case of couchDB, but either ways, the point I was trying to make was that RDBMS was a way to think of Schema as being the most important artifact while NoSQL allows us to get over that. With NoSQL, the Idea was something else. What that Idea was depended on the flavor you chose. I could be wrong. Hoping for more expert comments.
 
Kyle Banker
author
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Arun,

I can speak for MongoDB, which does make it easy to change schemas in the fly. It's easy, for instance, to do so lazily by writing code that can respect the old schema while updating it with it's next accessed. If changing the schema also means changing indexes, well, that's the sort of schema migration that's essentially analogous to that of an RDBMS: it may require some planning.

Kyle
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic