Hello
I come from a world of relational database butI curious about nosql for a project I have in mind.
I like to make a invoice app and now I need to make the database layout.
For a screen I need all the customer, another displayed subscriptions and another invoices.
in a relatioonal database I would say.
A customer can have multiple invoices and a invoice can have multiple subscriptions,
Now I wonder how this works with a nosql database.
Roelof
Hello @Roelof_Wobben
It is great that you want to utilize the strong features of MongoDB. As you mention you have a solid SQL background. To get the most out of an noSQL Setup, you need to change the way of thinking about schema design. Your first goal will no longer be to get the maximal normalized Schema, Denormalization is not bad, the requirement of your queries will drive your design. The story will start to think about a good schema design. In case you move the SQL normalized Data Model 1:1 to MongoDB you will not have much fun or benefit.
You can find further information on the Transitioning from Relational Databases to MongoDB in the linked blog post. Please note also the links at the bottom of this post, and the referenced migration guide .
Since you are new to MongoDB and noSQL I highly recommend to take some of great and free classes from the MongoDB Univerity:
Generally data modelling is a broad topic to discuss, this is due to many factors that may affect the design decision. One major factor is the application requirements, knowing how the application is going to interact with the database. With MongoDB flexible schema characteristic, developers can focus on the application design and let the database design conform for the benefit of the application. See also :
A summary of all the patterns we’ve looked at in this series
You may also can checkout:
This is just a sample which can get you started very well. In case this is going to be a mission critical project
I’d recommend getting Professional Advice to plan a deployment There are many considerations, and an experienced consultant can provide better advice with a more holistic understanding of your requirements. Some decisions affecting scalability (such as shard key selection) are more difficult to course correct once you have a significant amount of production data.
Hope this helps to start, while getting familiar and all time after, feel free to ask you questions here - we will try to help.
Regards,
Michael
You can also see this course M100 MongoDB for SQL Pros
University courses are free,to watch the videos just register,and if you want you will do the exercises
to get certification,else you watch just the videos.
M320 was nice M100 is the same instructor Daniel Coupal
Thanks all,
This is not for a mission critical project but a project that I made for a hobby.
I look now at mongo because I develop in smalltalk and there mongo is a lot used
Congrats!
I started with PL/1 and smalltalk/DB2 in the early 90th and some code is still active 
Since a long time, unfortunately, I had no smalltalk project - good to hear that it is still around a that MongoDB is used there. I will do some research just out of curiosity.
Michael
Hello @Takis,
thanks for pointing to M100 MongoDB for SQL Pros I missed that out to mention. It is a new Course, new style, the focus of M100 is more on the transition from SQL (tabular databases aka as relationonal) to MongoDB. Where as M320 is focusing an schema design aspects. @Roelof_Wobben I’d recommend both just go for the M100 first.
Cheers
Michael
Thanks
I work now a lot with Pharo (https://pharo.org/).
No idea if it’s still the same as the orginal smalltalk
Hi @Roelof_Wobben,
Are you using a MongoDB driver or API with Pharo? If so, which approach are you using and how has your experience been so far?
Pharo doesn’t currently have an officially supported driver, but it looks like there is a community-supported driver with partial feature support: https://github.com/pharo-nosql/mongotalk.
Regards,
Stennie
The relationships are the same, as the data entities are same - the one-to-many, one-to-one, etc. How you store the data is the main difference between relational and MongoDB document model (and of course, how you query too).
The one-to-many relationships can be modeled with document references or with embedded documents. See Model Relationships Between Documents.
The customer has the customer details, and the subscriptions (or plans subscribed to). The subscriptions, can be multiple. These can be stored within the customer collection as an array of subscription objects (or embedded documents).
The invoices have header and lines. These are stored as a single collection. The header details and lines as an array of line objects. Each line represents the subscription billing info.
@Stennie I use this as driver : voyage you can find it in the same repo
my xp for now is good but I have to say I only have used it in a tutorial.
@Prasad_Saya Thanks for showing me this
Hi @Roelof_Wobben,
Thanks for confirming! Voyage is an object persistence abstraction on top of the mongotalk driver I found earlier, but also supports a few different NoSQL databases.
I haven’t played with Smalltalk for a long long while, but like @Michael I’m also curious to see how it has evolved .
Regards,
Stennie
