Need some basic tips

Hi all,

Currently I am working on a Next.js project for collectors of comics. We opted for MongoDB as our database, but since this is a crowdsourced database project I could use some pointers and tips from the experienced MongoDB community.

So simply said its a crowdsourced database where users can add entries (comics) into the database, and also sell the items they have added into the database. So simply said, a user has a Spawn comic that isnt in the database yet, he can add it, and later sell this item from his account as well.

I am having difficulties in going from relational databases (sql) to MongoDBs nosql and seeing the best schematic and architecture for this project in MongoDB. Anyone got any pointers, tips or suggestions?

Hey Kevin,

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: