3 ms·

Quite honestly i often do not understand the extreme focus HN puts on NoSQL databases, as if it would be the new solution that fits every problem. The point is

by buster 14y ago

Quite honestly i often do not understand the extreme focus HN puts on NoSQL databases, as if it would be the new solution that fits every problem. The point is that SQL solves a lot of problems rather well and every NoSQL database has its own drawbacks. In the end you have a lot of NoSQL databases that solve some specific problems particularly well but have major drawbacks in other situations. SQL databases tend to fit a lot of solutions quite well, they are tested, stable, do transactions, can even scale and (for me) most important: SQL is a standard, the query language is well understood and documented, it is relatively easy to switch between SQL databases. But it's for practical purposes impossible to switch between a given set of NoSQL databases, let alone you need to learn a lot of new things or need another set of developers. Recent example in my project: I had a problem that did fit particularly well into Redis (small, self contained writes) but i also needed good querying capabilites. So after fiddling around with Redis and trying to make it work i had to abandon Redis. Next choice would have been: MongoDB or MySQL. The project already uses a MySQL server and i am easily able to replace MySQL with SQLite, Postgres or Oracle by using an ORM (SQLAlchemy). So the choice was easy. MongoDB would have been the worse choice but a possibility. I'd wish someone would come up with a common query language that could be reused on different NoSQL databases, that would make NoSQL much more an option. UnSQL[1] looks abandoned :( So after all: Every problem has its solutions, every program a good fit of a database. Either NoSQL or SQL, don't just point to some NoSQL database because it is the current buzzword, but ONLY because it can solve a problem better then a given SQL database. Then it doesn't matter if you call it SQL or NoSQL. Your NoSQL solution simply needs to redeem the benefits of SQL (standardized query language, transactions) with other benefits. [1] http://www.unqlspec.org/display/UnQL/Home http://www.unqlspec.org/display/UnQL/Home

jpalomaki 14y ago
I think the same applies to quite many new innovations on our field. They look interesting, because they make things simple. Things that used to be very complicated. The problem is that in some cases there are reasons why the things are complicated. Quite often it is easy to dismiss these issues during the initial crush with the new technology. "Sure I can live without transactions, why would I need to enforce schema for my objects, who needs type information in language" Once the initial crush is over, people start slowly adding features to make the shiny-new technology look more like the old stuff. Enforce JSON schema for Mongo, add lightweight type information for Javascript functions etc. Usually the thinking goes we are just adding these few good bits of structure from the Old Technology, surely we are not going to replicate the bloat and complexity.

by buster 14y ago

jpalomaki 14y ago

I think the same applies to quite many new innovations on our field. They look interesting, because they make things simple. Things that used to be very complicated. The problem is that in some cases there are reasons why the things are complicated. Quite often it is easy to dismiss these issues during the initial crush with the new technology. "Sure I can live without transactions, why would I need to enforce schema for my objects, who needs type information in language" Once the initial crush is over, people start slowly adding features to make the shiny-new technology look more like the old stuff. Enforce JSON schema for Mongo, add lightweight type information for Javascript functions etc. Usually the thinking goes we are just adding these few good bits of structure from the Old Technology, surely we are not going to replicate the bloat and complexity.