Where is your coin?

Some time ago people used to believe that you should bury a person with a coin in his mouth in order to pay the ship (or at least to guarantee a good place in the ship) to the land of the death.
If even in the land of the death, in the other world, there isn't free entrance, imagine here, imagine in the software's land. In a nutshell: there isn't free lunch. But why all this death, lunch talks; are you hungry? Are you afraid of dying?

No, absolutely not! The question is that people still think as new technologies as a free lunch, something like, an all around solution. If you need speedy them you should let it go the versatility, if you want all around solution them forget the speedy and welcome to the complexity nightmare; the blanket is not big enough for everyone.

I guess that all of you already heard about those Agile things like XP, Scrum and others, they are not really the same thing but all of them propagate the idea of: postpone as much as you can the decisions, most of the time you will realize that they are not needed or you will have the enough knowledge to do it right; I completely agree with that (by the way it doesn't means that the decision should not be made or it should be a no meaning decision, like a lot that we see around).

And them you come to NoSQL alternatives, quite flexible and it seems to fit so smoothly that it is like a temptation. No schema, you are so free to change it that you can even have different versions of data in a productive environment, really nice. Do you remember that we need to give the coin to the punter? Well, the NoSQL is a really light because of the simplicity of its schema, no rules, but it has a cost, the queries.
Once you go for this kind of solutions you need to pay in the queries, you don't have the power of the relational databases here. If in one end you don't need to think about the schema in the early beginning at the other end you DO need to think about how you are going to look for that information in the future.

Most of those solutions requires you to duplicate data if you want two different queries at the same time, or you need to create a view that will be your query, or simply no query at all, just a sequential access to the data (in a predefined order). The benefits? Fast, light, easy to distribute, but you need to pay a price for that.

So are they not really going to work in the real world? Absolutely not! Do not misunderstand me, they have a place, and I guess a big one. But we need really to understand what kind of application we are going develop, in the early beginning to know if it fits or not, and to address the needs of the technology.

The point here is: you need to know with whom you are dealing; do not take only the nice words of Agile and NoSQL; otherwise you will fall in the sing of the sirens and your ship will crash the rocks of reality.

As usual I will let a link here, I guess it will help you all to clarify what I am talking about the drawn backs of the NoSQL technology (in this case Cassandra): WTF is a Super Column