News for hackers. Stuff that matters.
Re:MongoDB queries don’t always return all matching documents by alkonaut on Wednesday June 08, 2016 @02:10PM (#11864252)
Yes. But "adding" is a pretty small subset of changes. If you need to do even a trivial migration like the classic "merge first and last name columns into a single column" is pretty hairy if you have a dozen legacy apps that assume "customers" have "firstname".

In the end it means you give the data an elevated role in the system, and you write the code around the data. When the code would be cheaper to write or maintain with a different data representation - you can't. It's a comfortable situation for a while, but when you eventually grow out of the current system it's a world of hurt.

Like I said - it's two bad (non) solutions but I very much prefer duplication, isolation, inconsistency, a forest of small obscure APIs etc. where I can add/remove/normalize/denormalize/add caching etc - to "the data is the ground truth and the schema we can only change through addition" non-solution.

Re:MongoDB queries don’t always return all matching documents by catnaroek on Wednesday June 08, 2016 @02:56PM (#11864644)
> In the end it means you give the data an elevated role in the system, and you write the code around the data.

That's how things are meant to be. The structure of a program naturally follows that of the data it manipulates.

> When the code would be cheaper to write or maintain with a different data representation - you can't.

Who says that? The real problem is that most programming languages aren't capable of integrating database schemas into the type-checking process, so when you change a schema, it's difficult to make sure applications follow through in a consistent manner. That's what makes change unnecessarily risky and painful. But it's possible to do better than that: http://impredicative.com/ur/