4 ms·
> Usually if you have a static schema you also have SQL, > which makes migrations a lot easier. I'm not sure I follow. MongoDB doesn't have a static schema s
by jt2190 14y ago
> Usually if you have a static schema you also have SQL,
> which makes migrations a lot easier.
I'm not sure I follow. MongoDB doesn't have a static schema so there's less work to do when migrating data. No temp tables, no DDL, no disabling of triggers, etc. So my definition of "easy" in this case was "fewer things to do", not "requires less expertise."
> I want to guarantee that my data is in the right
> structure, with the right types, and right relationships.
We know that having the right types, structure, and relationships are valuable, but since there is no context here, we can't know whether they're more or less valuable than other factors. (Note we've already assumed that the data is easily modeled in a relational structure AND in a document structure... If we're wrong about that this whole conversation may be moot.)
- wvenable 14y ago> MongoDB doesn't have a static schema so there's less work to do when migrating data. That depends on the operation. If I want add a column and provide a suitable default, that's a one-step process in a SQL database. Even better, I can do it from a GUI tool and generate SQL script ready to use in production. So my definition of easy is both fewer things to do and less expertise. Even taking a more complicated yet common example of taking a single field and turning it into a collection or table of values -- I think the SQL approach is still going to be less work. But I think the more complicated of a transformation you need, the less of a difference there is -- once you start writing a lot of code it doesn't matter if you are modifying a static schema or a dynamic one.
- jeltz 14y ago> But I think the more complicated of a transformation you need, the less of a difference there is -- once you start writing a lot of code it doesn't matter if you are modifying a static schema or a dynamic one. I agree with your general points but disagree with this. Since SQL provides excellent tools for set operations and integrity constraints even very complex migrations are simpler if you have SQL + a schema. SQL features like temporary tables, window functions, inserts using a select as source, CTEs, all help out when doing the really tricky transformations. Th exception is of course if you have millions of rows of data which you need to do a complex migration for. Then I do not think it ever can be easy, schema or not.