Database requirements
Determining the requirements of the application is the first and perhaps most important step in choosing the right type of database. This involves understanding the type of data that the application will store, the amount of data, the complexity of the data, data security requirements, and so on. By clearly mapping out these requirements, we can determine which database best fits the application and avoid unforeseen problems later on.
Data types
To determine the data types, it is helpful to list the data we want to store. These are the things we want to store.
- Account information
- Group information
- Room information
- Room feature information
- Planning data
- Application settings
- Logs such as access, error and audit logs
Most of the data for the rooms consists of typical data types like VarChar, float and integers. However, for some of the room features, we may need to store images, but this should be relatively straightforward.
Complexity of data
Based on the information provided in the "data types" section, we can draw some connections. Specifically, it appears that there is a relationship between rooms, people, and planning data, and that items can be connected to rooms. However, since items are also stand-alone, the situation is not overly complicated. One potential complication could arise if there is a separate database for each microservice, which is something that we will need to investigate further.
Database per service vs. one complete database
One of the main advantages of using a database per microservice is that it allows for greater flexibility and scalability in a distributed system. Each microservice can have its own dedicated database, which can be optimized for the specific needs of that microservice, such as performance, availability, or data integrity.
Using a separate database per microservice can also minimize the impact of modifications made to one microservice on the rest of the system. For instance, if a change is applied to the schema or data model of one microservice, it will not affect the functionality of other microservices, which can continue to operate as usual. This also promotes better collaboration among developers, as each team can have greater control over their own database when working on a specific microservice. In contrast, if a shared database is used, changes to the database schema can potentially break the functionality of individual microservices.
However, there are also some potential drawbacks to using a database per microservice. For one, managing multiple databases can be complex and time-consuming, requiring additional resources for administration and maintenance. Additionally, it can be challenging to ensure consistency and data integrity across multiple databases, especially if there is a need to perform transactions across multiple microservices.