Newbie need help with first bigger project (Design the project)

Hi all,

I am new to MongoDB and planning my first bigger project where I want to use it.

So, while figuring out how I could design the database I got some questions in my head. This project relates to kind of article management, so I wondered what I should use, embedded or referenced documents.

In a SQL database I would have at least 8 tables:

  • Main Table with basic information
  • Misc Table with some additional information
  • Sales Table for each article measurement
  • Barcodes table for barcode of each measurement
  • Price table for the sale prices of each measurement
  • Supplier table for each supplier
  • Purchase table for the supplier information of each supplier
  • Cost table for the supplier’s cost of each supplier

With following relationships in SQL:

  • Main > Misc = one to one
  • Main >> Sales = one to many
  • Sales >> Barcodes = one to many
  • Sales >> Prices = one to many
  • Main >> Supplier = one to many
  • Supplier >> Purchase = one to many
  • Purchase >> Cost = one to many

So, in MongoDB I see three designs I could use – for sure there are more which I don’t see.

The first:

  • Main with Embedded Misc
  • Main reference to Sales
  • Sales reference to Barcode and Prices
  • Main reference to Supplier
  • Supplier reference to Purchase and Cost

I would aspect this could have low performance and complex queries when adding new data to the second reference.

The second:

  • Main with Embedded Misc
  • Main reference to Sales with embedded Barcodes and Prices
  • Main reference to Supplier with embedded Purchase and Cost

Probably the best way?

The third:

  • Main with embedded everything

I would aspect this could end up in complex queries and data mess when getting some specific information.

I would be happy if someone can get a newbie into the right lane :blush:

Thanks, in advanced.

Hi Jake - I also am very new to MongoDB, my prior DB utilization being with Apple CoreData which is more like a database interface or driver into sqlite.

So with mongo I faced the same dilemma as you, quite a few tables (20), one with one to one relationship and the rest with one to many. Initially I thought I needed some many to many but as I got more familiar with the querying I decided it wasn’t necessary.

My first pass was with 1 database and 20 collections (documents). I found this very easy to work with, querys were pretty straight forward, editing/updating of data went smoothly as did creation of new document elements. Only document deletion was more than trivial. My biggest problem was seeding the database. The project requires a database with 30,000 ish collections which have default data, the user then goes forward with a process in which the user gathers data and inserts into the database. On completion the entire database is downloaded with the default data replaced by current data. With this design 12 of the collections must be loaded with the 30000 default items before the remaining 8 can be loaded with the related objectIDs for the one to many relationships. At least that was my experience. This appeared to be a monumental task so I put that on hold and moved to a second approach.

My second pass was to structure a database with one collection. I embedded some misc data and then nested the remaining. Actually pretty much like your Second. The database seeding then became very straight forward, I just created a JSON file with the desired nesting and used mongoimport to load my database. I am in the process of redesigning my app around this new database structure and have gotten to the stage where queries are pretty straight forward but I haven’t developed much beyond fetching the data. I haven’t yet got a clear picture of how to interface with the user to gather data.

I work alone and would love to have someone to kibitz with, interested?

Jim Rublee