Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I often liken NoSQL databases to dynamically typed languages.

With a NoSQL database, you have an implicit schema, but it will only be enforced and fail at runtime - when your code expects a field but failed to find it, for instance.

With a dynamically typed language, you have implicit types, but only enforced at runtime - when your code expects a value to be an int but finds a boolean, for instance.

And both are fine, there is a need for both. I can see how the flexibility of being able to change, well, everything by just flipping a switch in your head ("this is an int now") might be helpful for, say, data exploration problems.

It's just that in a production environment, these features of NoSQL databases and dynamically typed languages turn into massive sources of problems and oh god, just don't.



You and Lazare are right on the money. And the thing with the database is that the code that inserts/updates it has to agree with all the querying code about what the implicit schema should be - but it's implicit and scattered around your code - so on a large team it's very hard for everyone to understand that implicit contract and it's going to be a constant source of production bugs.

Schemas don't change that much compared to code, having a strict schema enforced by the database saves you so much time and pain and downtime in the long run.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: