0

I'm currently attempting to write some data on MongoDB to store character data, stuff like their name, description, etc. until there it's fine. But I run into situations where to me it's logical to split the data into a separate collection to avoid redundancy and to make it easier to update, for example:

  1. Normally I'd have a separate table to store "rarity" data which has a reference to a file path for the icon, the name, the id/number, etc. And then from the "characters" table I'd have a reference to the entry. But I heard these kind of relationships are frowned upon and that it could be easily embedded into the documents. But I think that if I were to update a "rarity" entry that means I'd have to update countless of "characters" entries.

  2. Similar to the situation above, some "characters" may share some "skills," to me it sounds logical to have each "skill" in a separate collection and then have a relationship because if I were to update a "skill" that means I would need to update multiple entries. Although this is a smaller situation since it wouldn't happen often or to all entries.

So this makes me wonder, in which situations is it good to embedded the data and dealing with the data duplication and "difficulty" of updating and in which situations is it good to separate the data?

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.