To understand how to internationalize MongoDB we need to talk briefly about its technical characteristics. So, it is an open-source database. It falls under the NoSQL database type. Unlike SQL, stored data has no predefined schema or structure. It was published for the first time in 2009 and is developed using C++, Go, Python, and JavaScript.
SQL vs NoSQL
| SQL | NoSQL |
| Data is related to a specific schema. | No pre-defined schema or structure. |
| Based on the relations between the tables. | No tables or relations. The structure is similar to JSON. |
| Data is stored in Tables. | Data is stored in Collections. |
| Table contains Columns. | Collections contain Documents or BSON documents. |
| Table contains Rows. | Collections contain Fields. |
| Primary key: any unique column. | Primary key: created automatically. _id |
From the above comparison, it is quite obvious why NoSQL is popular these days! In the last few years, the amount of exchange and the volume of non-structure data has become huge. Traditional databases and SQL have a lot of challenges and limitations to deal with such types of data. Here are a few benefits of MongoDB of type NoSQL:
- Easily scalable.
- You can store any type of data.
- You can use your favorite way to manipulate data on MongoDB as it comes with no predefined structure.
- High performance and speed.
- The ability to deal with any amount of unstructured data.
- MongoDB is suitable for both small or large companies.
MongoDB Internationalization (i18n)
The following are among the important preparation points to tackle to internationalize MongoDB:
Collation
You need to set the appropriate collation during the database creation.
Schema Design & Architecture for Multilingual data
Designing a Schema for a multilingual database is not an easy task. This is because good architecture requires the following:
- Full understanding of the business needs and technical requirements of the project.
- A good Schema must be able not only to fulfill current requirements but also to accommodate and to deal with subsequent changes and requirements in the future without reconstruction.
- Deep knowledge of the technical characteristics of the database program and utilization of every feature in it that makes the final database scalable, stable, secured along with a strong performance.
- Also, there is no shortcut or one solution for a well-designed schema. The same design can be perfect or no depending on the project’s requirements. Let’s see an example and demonstrate how many Schema designs can be provided:
Let’s say we have a Product Collection with the following data: ID, Name, Description, Availablity (True or False), Price & Currency.
The requirement is to Design a schema to internationalize the product so it can be stored, updated, retrieved easily in multiple languages.
From the above Collection, you can see that some documents are language relevant: Name, Description, Price, and Currency. But, ID and Boolean value of availability are not language-dependent.
Solution 1
Is to create a collection per language:
Solution 2
Within only one Product collection, you can create the languages inside it.
Solution 3
In solution 2, we split the collection per language. Another solution also within the same collection is to split per language-dependent field :
Solution 4
We can create something like a dictionary within the collection to group content per language while separating the language-independent content:
These are 4 solutions and be sure that there are many more. But what is the best one? Simply each of them theoretically is valid. But practically to decide the best one, there are factors to help you to make the right decision:
- The frequency of changes such as adding or removing new products.
- Are you doing the schema architecture for the product for the first time? Or you are customizing an already built one. Because sometimes extending from an existing Collection is a better solution for complex designs already in production.
- If you are customizing the schema, what is the level of dependency between the collections?
- What is the volume of documents? If it is too large it may exceed the MongoDB document size limit.
- The performance is important and sometimes it is crucial and must be the first priority.
- What is the cost and effort needed for future maintenance?
- How much your design is flexible and scalable?
To conclude, the key here to achieve the best result is the perfect communication between the Solution Architect and all the stakeholders along with the deep understanding of the technical requirements and the database platform capabilities and limitations. Of course, the experience and the knowledge gained from previous similar projects facilitate a lot in the decision-making process.
Feel free to leave a comment or to Contact Me for an open discussion!