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.
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 :
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.
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
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
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.
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.
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 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.
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_hoeller I’m also curious to see how it has evolved .