Welcome to the community!
The first rule of thumb you’ll hear when modeling data in MongoDB is “data that is accessed together should be stored together.” So carefully consider your queries to determine the best way to model your data.
It sounds like you’re going to want to have a collection named something like Comics that will contain all of the comics. Where things get tricky is how you want to handle sales and users.
When working with a relational database, you’d probably have a table for comics, a table for sales, and a table for users. Then you’d probably create references between the three.
When using MongoDB, you’ll want to consider how you’re going query the data. How will you view the sales? Will they be displayed on a user’s profile page or on a comic page or both? You may find yourself duplicating data–and that’s ok–especially if you won’t be updating it very often.
I’ll share a few resources that will help you get started in data modeling:
Free MongoDB University Course all about data modeling:
Schema Design Patterns blog series. My guess is that Extended Reference, Subset, and Computed patterns will be helpful to you as you figure out how much data you want to duplicate and if you want to pre-compute any stats.
I can’t resist the chance to plug my own content. Here are some anti-patterns to avoid:
Finally, since you’re moving from a relational database to MongoDB, you may find this blog series helpful: