3 ms·

This is (probably) an artifact of Mongo's schema-less nature; when you don't have tables with structure, every document you store has to detail its own schema i

This is (probably) an artifact of Mongo's schema-less nature; when you don't have tables with structure, every document you store has to detail its own schema inline. In a relational database, you have columns with names and types, and that info is shared by all of the rows. In Mongo, every cell has to specify its name and type, even if that layout is shared by every other cell in the document. Mongo's way is more flexible, but it's terrible for storage efficiency.

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 ago
  There's something beautiful about normalizing the storage of denormalized schemas.
  - jgalt212 6y ago
    Yes, 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.

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 ago
There's something beautiful about normalizing the storage of denormalized schemas.
- jgalt212 6y ago
  Yes, 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.