3 ms·
/caveat i know nothing about how mongo is storing data and haven’t used it since 2010 it doesn’t really have to approach the schemas that way. one would think
by rubyfan 6y ago
/caveat i know nothing about how mongo is storing data and haven’t used it since 2010
it doesn’t really have to approach the schemas that way. one would think it would be optimized for repeat schema in the same way one might create the schema definition and then reference it in packing and unpacking the data. seems like if there was schema overhead taking up storage unnecessarily that could be optimized relatively easily.
having schema references also might be a good management tool to understand which records vary potentially due to an application evolving it’s needs.
- carlps 6y agoThere's something beautiful about normalizing the storage of denormalized schemas.
- jgalt212 6y agoYes, and the sooner you do it the better. But doing it during project planning / experimentation phase (or when you don't know what the final result should be yet) will really just slow you down. In many ways, very similar to the static / dynamic language trade offs.
- thomascgalvin 6y ago> one would think it would be optimized for repeat schema I don't think that's the problem Mongo is designed to solve. Mongo's promise was the ability to work with un- and semi- structured data, and it would make sense if its optimizations were focused on that problem, not on reducing overhead when someone tries to strongarm it into being MySQL. Generally speaking, if your data is structured well enough that you can define a schema ahead of time, you're better off with a traditional RDBMS, because that's the problem an RDBMS is designed to solve.