Reputation: 167
Just a general question here - I'm doing some self paced learning on MongoDB and to get off on the right foot I'd like an opinion on how to organize collections for a sample budget application.
As with any home budget I have 'Categories' such as Home, Auto and I also have subcategories under those categories such as Mortgage and Car Payments.
Each bill will have a due date, minimum amount due, a forecast payment, forecast payment date, actual payment and actual payment date.
Each bill is due to 'someone', for example Home, Mortgage may be due to Bank of America, and Bank of America may have contact info (phone, mailing address).
Making the switch from a Table structure to Mongo is a bit confusing, so I appreciate any opinions on how to approach this.
Upvotes: 4
Views: 2575
Reputation: 3760
The question is very general. In general :), the following principles apply to schema design in MongoDB:
The layout of your collections should be guided by sound modeling principles. With MongoDB, you can have a schema that more closely resembles the object structure of your data, as opposed to a relational "projection" of it.
The layout of your collections should be guided by your data access patterns (which may sometimes conflict with the previous statement). Design your schemas so you can get the info you need in as few queries as possible, without loading too much data you don't need into your application.
You often can, and should, "denormalize" to achieve the above two. It's not a bad thing with MongoDB at all. The downside of denormalizing is that updates become more expensive and you need to make sure to maintain consistency. But those downsides are often outweighed by more natural modeling and better read efficiency.
From your description above, it sounds as if you have a rather "relational" model already in mind. Try to get rid of that and approach the problem with a fresh mind. Think objects, not tables.
Upvotes: 2