With all the buzz over noSQL, I installed one a few weeks ago, ran a few examples and smiled a lot since we are now back to hierarchical, non normalized databases.
Many years ago, when I was working in the systems division of a large banking organization, we got constant pressure to move all the databases to a 'more modern SQL database. We resisted this since, besides the migration cost, the performance impacts would have been unbearable. The same justification of high transaction rates on large databases is the reason that noSQL is being touted as the solution.
However, people seem to have forgotten what the push was to move to SQL in the first place, and are at risk of repeating past mistakes. Go and search for CODASYL and all the debates which raged over hierarchical versus relational databases and the pluses and minuses of each of the technologies and you will see that the conversations are not all that different.
Each approach has its place and the key is always using the solution that best fits the problem and not bending the problem to fit the solution.
Since each noSQL implementation I looked at has its own API, if you are going down the noSQL path, (and I do not like pre-emptive coding) at least encapsulate the data accesses so if you decide to move to a different infrastructure, that the cost of moving is limited.
Many years ago, when I was working in the systems division of a large banking organization, we got constant pressure to move all the databases to a 'more modern SQL database. We resisted this since, besides the migration cost, the performance impacts would have been unbearable. The same justification of high transaction rates on large databases is the reason that noSQL is being touted as the solution.
However, people seem to have forgotten what the push was to move to SQL in the first place, and are at risk of repeating past mistakes. Go and search for CODASYL and all the debates which raged over hierarchical versus relational databases and the pluses and minuses of each of the technologies and you will see that the conversations are not all that different.
Each approach has its place and the key is always using the solution that best fits the problem and not bending the problem to fit the solution.
Since each noSQL implementation I looked at has its own API, if you are going down the noSQL path, (and I do not like pre-emptive coding) at least encapsulate the data accesses so if you decide to move to a different infrastructure, that the cost of moving is limited.
RSS Feed